Controlling optimization and debug info in Release builds in .Net applications

Posted on by Matthew Skelton (@matthewskelton)

Some interesting info on controlling optimization and debug info for deployed .NET applications:

…the little-known little-used [.NET Framework Debugging Control] section of a .INI file. These help guide and control the JIT. From MSDN:

This JIT configuration has two aspects:

  • You can request the JIT-compiler to generate tracking information. This makes it possible for the debugger to match up a chain of MSIL with its machine code counterpart, and to track where local variables and function arguments are stored.
  • You can request the JIT-compiler to not optimize the resulting machine code.

So Mark suggested this (emphasis mine):

You can have the best of both worlds with a rather neat trick. The major differences between the default debug build and default release build are that when doing a default release build, optimization is turned on and debug symbols are not emitted. So:

    • Step 1: Change your release config to emit debug symbols. This has virtually no effect on the performance of your app, and is very useful if (when?) you need to debug a release build of your app.
    • Step 2: Compile using your new release build config, i.e. *with* debug symbols and *with* optimization. Note that 99% of code optimization is done by the JIT compiler, not the language compiler, so read on…
    • Step 3: Create a text file in your app’s folder called xxxx.exe.ini (or dll or whatever), where xxxx is the name of your executable. This text file should initially look like:


[.NET Framework Debugging Control]
GenerateTrackingInfo=0
AllowOptimize=1

    • Step 4: With these settings, your app runs at full speed. When you want to debug your app by turning on debug tracking and possibly turning off (CIL) code optimization, just use the following settings:


[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

[http://www.hanselman.com/blog/ DebugVsReleaseTheBestOfBothWorlds.aspx]

 

Converting a byte[] to a System.String

Posted on by Matthew Skelton (@matthewskelton)

Discussion at http://weblogs.asp.net/oldnewthing/ archive/2004/09/07/226306.aspx:

For some reason, this question gets asked a lot. How do I convert a byte[] to a System.String? (Yes, this is a CLR question. Sorry.)

You can use String System.Text.UnicodeEncoding.GetString() which takes a byte[] array and produces a string.

Note that this is not the same as just blindly copying the bytes from the byte[] array into a hunk of memory and calling it a string. The GetString() method must validate the bytes and forbid invalid surrogates, for example.

You might be tempted to create a string and just mash the bytes into it, but that violates string immutability and can lead to subtle problems.

The MSDN help for Encoding.GetString() is here:

http://msdn.microsoft.com/library/default.asp? url=/library/en-us/cpref/html/ frlrfSystemTextEncodingClassGetStringTopic1.asp

 

Networking at Iridium

Posted on by Matthew Skelton (@matthewskelton)

I attended a seminar on .Net hosted by Iridium today. Met some interesting people, including a guy from Philips Belgium, a Micro$oftie developer, and another .Net code junkie (some useful links there).

The seminar covered Classic ASP-ASP.NET Interop; a bit on COM Interop; Windows DNA plus .Net for 3-tier development; Windows XP SP2; and VS.Net 2005/.Net 2.0.

Classic ASP-ASP.NET Interop

Early-adopters tend to stumble upon problems with new technology (sounds familiar!?!). Co-existence between Classic ASP and ASP.NET is possible, but a bit of a hack. In particular, the sharing of Session information is difficult; easier if data types in the Session are simple, and can be stored in a SQL DB, but otherwise tricky (storing big objects in the Session is bad practice anyhow, but that’s another story). Direct interaction between Classic ASP and ASP.NET is possible by using COM objects – either wrapping a .Net class as a COM object, or by using a RCW on a VB-style COM object. Btw, keeping the 3-tier model alive in ASP.NET perhaps needs some discipline, with “visual” components such as DataGrid so easily accessible from the Presentation layer.

COM Interop

.Net can expose functionaloty as COM objects with ease. To wrap a C# class as a COM object, give it Guid and InterfaceType attributes:

using System.Runtime.InteropServices;
...
[Guid("F09684D5-D3EF-4838-8BBC-726EF122566F),
InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface MyComExposedNetInterface
{
...
}

Then declare a class which will act as the CoClass:

[Guid("0D53A3E8-E51A-49C7-944E-E72A2064F938"),
ClassInterface(ClassInterfaceType.None)]
public class MyNetComClass : MyComExposedNetInterface
{
...
}

The ClassInterfaceType.None directive restricts the methods exposed via COM to those defined in that particular .Net class (rather than those in base classes etc.). Compile and go! .Net registers the COM object internally, so that clients callinng into the COM object actually call into the .Net runtime, which manages the location and versioning of the component – nice.

Windows DNA plus .Net for 3-tier development

In a Three-Tier model (Data, Business, Presentation), the Business layer should be stateless. This means that the Presentation layer should pass in all the parameters it needs in order to retrieve the information it requires. The Data layer in .Net is simplified compared to DNA because ADO.NET handles much of the Database connectivity issues for the programmer.

Windows XP SP2

Windows Firewall, NetSh.exe,
blah, blah, Popup-blocking in IE, blah. More interesting was news that the entire of Windows XP SP2 (i.e. a good chunk of the Windows code base) has been recompiled with the /gs switch.
Some cunningness with “magic” numbers placed on the stack between function calls means that buffer overflows can be trapped more reliably. SP2 may break apps due to DLL versioning, but this can be fixed by using Side-by-Side deployment and application .manifest files to direct the app (well, the application loader) to the correct DLL version. Managing the XP Firewall could be a pain for software developers. I asked about MSXML versioning – it’s a real pain to be stuck with an ancient parser.

VS.Net 2005/.Net 2.0

Lots of nice goodies in VS.Net 2005 [side-note: some of this testing functionality already exists in Application Center Test], though only if you pay Big Bucks. The Team System will have integration IDE, Bug/Issue Tracking, Bug Reporting, Testing, Deployment, etc. Bugs
will be automatically added to a database, complete with line-number and filename where the error occurred. Generics will enable generation of specific classes on-the-fly, rather that at compile-time. ASP.NET 2.0 will have built-in Controls for Authentication, Login, User Profile management, to name a few, along with ability to add new .aspx pages after deployment.

Version numbering madness!

Posted on by Matthew Skelton (@matthewskelton)

…the version numbers of Knuth’s masterpieces TeX and METAFONT are converging to pi and e, respectively. – via /.

Understanding Delphi’s perception of COM

Posted on by Matthew Skelton (@matthewskelton)

Delphi is great for COM if you want to do something simple; as soon as someting a little more complex is needed, COM in Delphi can be a real headache. Here is a braindump from a recent investigation:

The LocalServer class registration function CoRegisterClassObject is called for each Class Factory registered with the Singleton ComServer object in TComServer.Initialize. Class Factories are registered in the initialization section of units in which they are defined, and TComServer.Initialize does not get called until after Application.Initialize has been called (using some InitProc hackery in first ComObj and then ComServ). Crucially, ComServer is a helper object to guarantee registration of all the Class Factories in the application (or DLL), so ComServer.ObjectCount refers to the number of objects it has helped to create (via Class Factories) not the number of references held (say, externally) to any particular COM object.

A post from b.p.d.activex.controls.writing by one Patrice Corteel explains further:

Now let’s go a step further in COM threading model discussion and look at local and remote servers versus in-proc servers.
A Delphi local or remote exe server has a main thread which calls CoInitialize which makes it an apartment. And as a default behaviour, every COM component based on the delphi COM framework is created in this thread and marked as apartment threaded. If you explicitly spawn new threads you can initialize them as you want but you must get a marshalled interface to call components created by your main thread.
If you want to create free threaded components it’s far more difficult since you can’t rely directly on Delphi implementation and you have to rewrite large parts of ComServ and subclass many of ComObj classes. I’m currently working on this topic and I’ll post more on this when I am over with tests.

Note that if lengthy initialisation is needed, set ComServer.StartSuspended to True before Application.Initialize; this causes the class factories to be registered with the REGCLS_SUSPENDED flag, and ComServ.InitComServer makes the required call to CoResumeClassObjects to activate them again.

References