Ildasm: Viewing attributes

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/ildasm_viewing_attributes.htm]

Yesterday I mentioned ILdasm to view the meta data on an assembly. One of the benefits of .Net is that it requires meta data for all assemblies. You can even create your own strongly-typed meta data via attributes. For example, both NUnit and MSTest use attributes to indicate that a certain method is a unit test. Because all the meta data is public, these external programs can use reflection to loop through all the methods in an assembly, and check which methods have which attributes.

These attributes show up in the IL. If you use Ildasm to view a method, you'll see which attributes it has. The IL snippet below has both the [TestMethod] attribute used by MSTest, and my own custom [Duration] attribute.

.method public hidebysig instance void  Duration_String_1() cil managed
{
  .custom instance void [Microsoft.VisualStudio.QualityTools.UnitTestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute::.ctor() = ( 01 00 00 00 )
  .custom instance void TestDemo.Duration.DurationAttribute::.ctor(float64) = ( 01 00 7B 14 AE 47 E1 7A 84 3F 00 00 )             // ..{..G.z.?..
  // Code size       18 (0x12)
  .maxstack  2
  .locals init ([0] string s)
...
  IL_0011:  ret
} // end of method Strings::Duration_String_1

Of course, you'd probably never use Ildasm to read the attributes, but it's good to know that everything is consistent - i.e. meta data is public for any .Net assembly - it's not cryptic information only for debug more or something (like a *.pdb). So it makes sense that external programs like MSTest and NUnit can read these attributes.

Measuring the CLR, using ILdasm

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/measuring_the_clr_using_idasm.htm]

I've been looking more at the .Net CLR, i.e. how .Net really works under the hood. Because most of my work and hobbies are application development, it's easy to take the CLR for granted.

I've been reading Don Box's (with Chris Sells) Essential .Net Volume 1: The Common Language Runtime. I'll try to blog more about each chapter as I read it. Obviously given the popularity of both authors, it's a good book. Even though it's for .Net 1.0, it's still very practical.

It makes it much easier to understand something if you can observe and measure a cause and effect. Many devs I see don't try to understand the CLR because they can't measure much about it - such as how much memory some code takes, how fast the code runs, what happens when it gets compiled, etc... For example, many devs use try-catch to do business logic checks, and don't worry about performance because it "works fast enough on my machine."

I'm no CLR guru (you can see the official Microsoft CLR bloggers here), but I'll be blogging my adventure digging deeper into the CLR.

To kick it off, I started with Ildasm (view MSDN tutorial here). As every .Net book points out, .Net languages (like C# and VB.Net) get compiled into MSIL - Microsoft Intermediate Language - or just IL for short. This allows .Net to be language independent, because no matter what language you code in, it gets compiled to the same IL. Ildasm lets you see that compiled IL.

First, you can see the IL Specification here.

You can run Ildasm by opening the VS command prompt and just typing "ildasm". If you go to File > Open, you can browse for an assembly, load it, and then view its IL and meta information.

Here are some immediate benefits of what you can see with IL:

1. Whether this is a debug or release assembly - the Debug version will have an extra line:
       // .custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute
2. The meta data for the assembly (like company name)
3. What other assemblies this one references.
4. The actual IL. So, for example, you could see the number of boxing and unboxing operations by checking for the box and unbox IL commands.
5. All the types and classes in the assembly.k

A super-version of IL, which can take an assembly and convert from the IL back to a .Net language is Lutz Roeder's Reflector. This is very useful for reverse engineering an assembly - even Microsoft's own system assemblies.

I'll blog more about this in my upcoming posts.

Logical puzzles

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/logical_puzzles.htm]

This is a cool website: http://www.techinterview.org/

It lists a bunch of logic puzzles that you'd likely see in a tech interview. Nice way to start the morning.

Adding an Event to a User Control (Code Sample)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/adding_an_event_to_a_user_control.htm]

I had talked about how to trigger an event from a UserControl.

This ability has many benefits, such as with refactoring. For example, suppose a UserControl is hosted on many different pages, and each page requires that the control have slightly different validation that incorporates values from the host page. One way to do this is to have the UserControl call a validation method on the host page.

Here's a code snippet you can download that shows how to have a UC call a method on its parent. The idea is to add an event member to the control, and hook it up with a delegate. (I had initially seen this technique from an article on MSDN several years ago).

This specific example has four files:

• A UserControl - RecordNav.ascx and RecordNav.ascx.cs
• A host page - HostRecordNav.aspx and HostRecordNav.aspx.cs

The UserControl contains an event "UpdateDate" and the host page adds a method to handle the event: RecordNav1_UpdateData.

    RecordNav1.UpdateData += new AspxDemo_Events_RecorNav.UpdateDataEventHandler(RecordNav1_UpdateData);

CNUG Presentation followup - MSBuild with source code samples

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/cnug_presentation_followup__msbuild_with_source_code_samples.htm]

Yesterday's presentation at the Chicago .Net Users Group went well. Paylocity sponsored it with a presentation on MSBuild: A Process Automation Language.

You can download the presentation and code samples here.

Here's the abstract:

.Net 2.0 introduces MSBuild – Microsoft’s new build engine with a process-oriented scripting language. While MSBuild is marketed for compilation and build processes, it is really a full-fledged automation language. It includes structured control flow, variables, refactorability, error handling, logging, and powerful extensibility. You can easily integrate MSBuild into your own enterprise processes and start adding value right away.

Multi-tasking with background processes

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/multitasking_with_background_processes.htm]

A miscellaneous thought for the day: Given enough time, what (non-computer) background processes do you run in your everyday life? Letting the dishes soak to get out a tough stain, or letting clothes air-dry?

If you have the time, these processes are very cheap yet effective. People who don't have the time pay for extra products to make these processes go faster (a powerful dishwasher, chemical cleaning products, or clothes dryer). It's the old cliche - time is money. Software development is the same way. Being able to just kick off a background process that does work for you can be a great way to increase productivity. It's like being able to do two things at once, such as integrating your code (continuous build on a build server) and doing local development, or running a local pre-checkin script to verify for unit test errors and reading a design doc.

It gets especially cool if you have access to other machines (or virtual machines), and you can kick off more than two things at once - like having a database integration test run on Machine X, performance tests run on Machine Y, Static Code Analysis / Unit Test coverage run on Machine Z, all while catching up on email.

All this really requires is the desire to multi-task, and the hardware to do it. Given that a computer is much cheaper than a developer, if one is multi-tasking properly, it could be well worth the investment

Presenting at Chicago .Net Users Group on MSBuild

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/presenting_at_chicago_net_users_group_on_msbuild.htm]

This Wednesday (Nov 15) I'll be presenting at the Chicago .Net User's Group on MSBuild: A Process Automation Language. Pizza starts at 6:30pm, the presentation at 7:00.

.Net 2.0 introduces MSBuild – Microsoft’s new build engine with a process-oriented scripting language. While MSBuild is marketed for compilation and build processes, it is really a full-fledged automation language. It includes structured control flow, variables, refactorability, error handling, logging, and powerful extensibility. You can easily integrate MSBuild into your own enterprise processes and start adding value right away.

It should be a good time.