The end of the year is always a good time to take a look back and evaluate progress. It seems like 2012 has been a busy year for me, so let's take a look back at Things I've Done, Things I've Learned, Cool Stuff that Happened, and some Thing I Didn't Get To.
Things I've Done
Speaking
It seems like I did a lot of speaking this year. Anyone who's heard me speak has probably picked up on how much I love it, so I try to get out to as many events as I can. This year I presented 33 sessions at 19 events. The events included 5 Code Camps: the 3 So Cal Code Camps, Desert Code Camp in Arizona, and the Silicon Valley Code Camp (my first time there -- wow, it's big).
The rest of the presentations were at various User Groups in So Cal as well as Arizona and Nevada. A big thank you to all of the user groups who hosted me; I always have a great time. (And not that I'm hinting or anything, but I'm available again this year -- just use the INETA request link on the right.)
Blogging
I wrote 54 blog articles this year (55 if you count this one). That's the most so far. The articles are a mixture of technical articles, book reviews, upcoming events, and answers to questions from session attendees. I even had a couple of 5 part series articles. It was nice to have some free time earlier in the year. I need to make sure that I set time aside specifically for technical articles.
New Sessions
I came up with 2 new sessions this year complete with code samples and walkthroughs: T, Earl Grey, Hot: Generics in .NET and Dependency Injection: A Practical Introduction. My goal was to come up with two sessions, and I'm glad that I had a chance to present the new topics. Dependency Injection has been a very popular topic, and I'm sure that I'll be speaking on that throughout the coming year.
Things I've Learned
It's been a big year for learning new things. As usual, most of my learning is just-in-time learning for whatever projects that I'm working on. I had a chance to work on a great WPF project (I really love XAML) that uses Prism (XAML application guidance from the Microsoft Patterns & Practices team). If you've been following my blog, you've seen my thoughts on the framework. And if you haven't been following my blog, you can catch up here and here (short version: Prism has worked very well for this particular project).
I've also learned quite a bit about Dependency Injection both through Mark Seemann's excellent book and from experience using it myself. I also had to do a bit of learning outside of my project requirements so that I could write the new session mentioned above.
And one of the big reasons I'm a fan of Dependency Injection is Unit Testing. I really dug in to Unit Testing this year, and I'm surprised at how quickly I took to it. I've used mocking and dependency injection to isolate units of code for testing. The one thing I like most about unit testing is that I can refactor with confidence. If there's a bit of clumsy code that needs to be reworked, I first make sure that I have good tests of the functionality. Then when I extract methods or update algorithms, I can be sure that the code is still working as intended. As I mentioned in an article earlier this year, I'm still not at TDD yet, but I find myself doing small bits of TDD during my coding process.
Honorable mention goes to MVVM and Tasks. I've been buried in MVVM and doing a bit of fine-tuning to make sure that I have good separation of concerns in the presentation of my applications. I've also dug into Tasks a bit deeper and have been learning about asynchronous calls, UI interaction, exception handling, and unit testing. Lots of good stuff.
And 2 of the most impactful books that I read this year are Clean Code and The Clean Coder. Clean Code has made me rethink some of the ways that I've been writing methods. I'm starting to think smaller with more layers -- something I was reluctant to do before. The Clean Coder has made me think more about myself as a professional -- making sure that my conduct is appropriate, that I'm clear with my communication, and that I live up to my commitments. This is definitely a process (both the code and me), so I'll keep moving forward in both areas in the coming year.
Cool Stuff that Happened
Probably the coolest thing that happened this year was being presented with a Microsoft MVP Award. It was a great honor to be recognized for my development community contributions, and I'm looking forward to attending the MVP summit with the goal of making lots of new MVP friends (in addition to the MVP friends that I already have).
I've been getting a bit of recognition at Code Camps as well. At the So Cal Code Camp in Los Angeles, I had someone ask if I was giving the Design Patterns talk again. And at the Desert Code Camp in Arizona, I had someone ask if I was talking about Lambda Expressions. These people attended my sessions the year before and still remembered not just me, but the topics as well. That makes me feel like I'm really making an impact with the topics that I present.
Another cool thing is that my blog is getting over 1,000 hits per month (I even had close to 2,000 in September). That might not sound like much (and it really isn't), but it's a big increase over the 250 to 350 hits per month that I used to get.
One thing that has directed some traffic to my blog is a mention on StackOverflow (thanks for the referral, Peter Ritchie). For some reason my articles on the BackgroundWorker component get a lot of hits. I guess it's because I have a soft spot for that component. I know that it will probably go away soon (it didn't get included in WinRT), but I'll hang onto it as long as I can. It's great at what it does.
Also for some strange reason, if you Google "MVVM Design Pattern", one of my articles comes up on the first page. That's driven a lot of traffic to my blog (which is really cool), but I'm not quite sure how I got ranked so high. I guess I shouldn't complain because it probably won't last too much longer.
Things I Didn't Get To
There were a couple of things that I didn't get to this year, but there's always next year. First, I was planning on getting my CTT+ certification (Certified Technical Trainer). I'm still interesting in pursuing it, but I didn't get to it this year.
I also didn't produce any technical videos this year. I was planning on putting together a handful of quick video tutorials on various topics (like lambda expressions and delegates) but never got around to it. A friend recently asked me for some feedback on a video that he's producing, and I think that might have given me the kick in the butt that I need to start making my own.
A Great Year Gone -- Another One Coming
Overall, it's been a great year. I'm learning and growing as a developer -- that lets me know that I'm still interested and haven't stagnated. I'm still having a great time speaking and mentoring, and I love to help other people. And it's been really great to get some recognition from the developer community.
There's a great year ahead. I've got some exciting things lined up. And I also have no idea what's going to happen with a lot of other things.
Take a few minutes to reflect on what you've learned this year and how you've grown as a developer. If you're not constantly learning, then you're probably falling behind. If you don't already attend a local User Group, find one. It's a great way to keep in contact with other developers, to find out what's going on outside of your company, and to learn about lots of great technologies.
Looking forward to another great year!
Happy Coding!
Monday, December 31, 2012
Monday, December 17, 2012
Update on Windows 8 Guidance
Last week (Five Months In: Working with Prism in WPF), I mentioned that application guidance for Windows 8 is still pending. As an update, Blaine Wastell published an article a few days ago with the roadmap for Windows 8 guidance: Prism on .NET 4.5 and the road to Windows 8 apps. So, it looks like we have something to look forward to from the Patterns & Practices team in the next few months.
Happy Coding!
Happy Coding!
Sunday, December 9, 2012
Five Months In: Working with Prism in WPF
Several months ago, I put down some initial thoughts regarding Prism: First Impressions: Working with Prism in WPF. Now that I've been working with Prism for five months, I thought it was time for a follow-up.
It turns out that my opinions haven't changed much from those first impressions. Prism is working out very well for the project I'm working on. Taking advantage of the modularity (and the independence of each module) has allowed us to quickly modify and add to our task workflows. We've managed to keep good separation and isolation which has made unit testing much easier. The navigation objects are working as expected. And the helper objects make the code much more compact, readable, and maintainable.
Prerequisites
I have confirmed my opinion that Prism is not for beginning programmers; there are a number of intermediate topics that are necessary to understand. What is interesting is that I have articles or presentations that are centered around these prerequisites. I didn't plan for this, it just turns out that the topics I've written about happen to revolve around the foundational knowledge required for Prism.
Here's the list from the previous article along with links to my materials:
Useful Features
In the previous article, I mentioned a number of features that I liked. That list is still accurate. I'll go into a little more detail on 2 of these features.
DelegateCommand
The DelegateCommand allows you to create an ICommand object with much less code. Commanding is used to data bind to buttons in the UI. Let's compare some code.
To implement ICommand yourself is not very complicated. But there is a lot of boiler-plate code in a custom object. Here's a sample command implementation (this is taken from the Dependency Injection session samples):
As we can see, there is quite a bit of code here, but we really only care about the last line (that assigns to the People property of the ViewModel). The rest is plumbing.
Compare this to using a DelegateCommand from the Prism framework:
This allows us to do the same thing (assign a value to the People property), but we can do this with just one line of code (the DelegateCommand constructor) instead of needing to create a custom class. The parameter of the DelegateCommand constructor is the "Execute" we want to perform ("Execute" is part of the ICommand interface).
ICommand has another method: "CanExecute". This returns true or false depending on whether the command can be executed. In our example, this always returns "true". But sometimes this is more complicated -- such as if we need to check a property or run some code. The DelegateCommand constructor takes a second parameter which is a delegate for "CanExecute". If you do not provide one, then "CanExecute" is always true.
As you can see, DelegateCommand makes our code much more compact. And if we don't want to use a lambda expression (or if our Execute is several lines of code), then we can use a standard delegate method instead. The result is that it is easier to see the intent of our code. Instead of looking through a custom command object for the Execute method, we have the code right here in the constructor (or a pointer to it in the case of a named delegate).
When you have a number of commands in the application, this makes a huge difference in the amount of code that needs to be written as well as the readability of that code.
NotificationObject
NotificationObject is another class that is provided by the Prism framework. This class implements the INotifyPropertyChanged interface. This interface needs to be implemented in order for data binding to work as expected in XAML. The interface itself is not hard to implement (just a few lines of boiler-plate code). The difference between NotificationObject and manual implementation has to do with the RaisePropertyChanged methods that are available.
When implementing INotifyPropertyChanged, you generally make a call to RaisePropertyChanged in the setter for a Property, such as this:
The RaisePropertyChanged method will alert the UI that the underlying property has been updated and that the UI should refresh the binding. Notice that this version of RaisePropertyChanged takes a string parameter.
In contrast, NotificationObject provides a RaisePropertyChanged method that takes an Expression. This lets us write code like this:
Your first thought might be, "I don't see much of a difference." But there is. Instead of using a string, we use an expression with the actual Property. This means that we get IntelliSense when we are creating this method. It also means we will get a compiler error if we type the property name incorrectly. And most importantly, if we rename our property, our refactoring tools will automatically update the RaisePropertyChanged method as well. Using properties over strings is definitely the way to go.
Nothing You Can't Do Yourself
I had an interesting conversation with someone about Prism. He asked me what I liked about it, and I told him that I really liked the DelegateCommand. His response was that you could create a DelegateCommand object yourself -- it's only about 15 lines of code. And he is absolutely correct.
Prism doesn't perform any magic. It consists of a set of helper classes and methods that you could implement yourself. But we don't have to. The Patterns & Practices team has implemented these for us and put them together in a package that is easy to use.
If you don't like any of the implementations, you are free to change them. Prism comes with all of the source code (including unit tests). So you can enhance or re-implement any of the features. My experience is that the features are well-implemented and have met my needs.
What About Windows 8?
My one disappointment around Prism is that it looks like there won't be an implementation for Windows Store Applications. Prism covers a lot of platforms: WPF, Silverlight 5, and Windows Phone 7.5. The latest rumors are that there will be a different guidance package from the Patterns & Practices team for Windows Store Applications, and I have not been able to hunt down a beta or a release date at this point.
If you are developing Windows 8 desktop application with WPF, then Prism will work just fine. But for Windows Store Applications, we will need to wait for another solution.
[UPDATE: There has been announcement regarding guidance for Windows Store Apps. More info: Update on Windows 8 Guidance]
Wrap Up
As I mentioned, my opinion of Prism has not changed much from my initial impressions of working with it. It has been a very good framework for my current project, and I will keep it in mind for future projects. If you are working on fairly straight-forward applications or applications with just a few screens, then Prism may be more than you need. But if you are working on modular or enterprise-level applications, it may be just what the doctor ordered.
Happy Coding!
It turns out that my opinions haven't changed much from those first impressions. Prism is working out very well for the project I'm working on. Taking advantage of the modularity (and the independence of each module) has allowed us to quickly modify and add to our task workflows. We've managed to keep good separation and isolation which has made unit testing much easier. The navigation objects are working as expected. And the helper objects make the code much more compact, readable, and maintainable.
Prerequisites
I have confirmed my opinion that Prism is not for beginning programmers; there are a number of intermediate topics that are necessary to understand. What is interesting is that I have articles or presentations that are centered around these prerequisites. I didn't plan for this, it just turns out that the topics I've written about happen to revolve around the foundational knowledge required for Prism.
Here's the list from the previous article along with links to my materials:
- Dependency Injection / Inversion of Control
Dependency Injection: A Practical Introduction - Interfaces
IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces - Delegates / Func<T> / Action<T>
Get Func<>-y: Delegates in .NET - Lambda Expressions
Learn to Love Lambdas - Events and Event Handlers
User Controls and Events - Model-View-ViewModel (MVVM)
Overview of the MVVM Design Pattern - Various other Design Patterns
Learn the Lingo: Design Patterns
Useful Features
In the previous article, I mentioned a number of features that I liked. That list is still accurate. I'll go into a little more detail on 2 of these features.
DelegateCommand
The DelegateCommand allows you to create an ICommand object with much less code. Commanding is used to data bind to buttons in the UI. Let's compare some code.
To implement ICommand yourself is not very complicated. But there is a lot of boiler-plate code in a custom object. Here's a sample command implementation (this is taken from the Dependency Injection session samples):
As we can see, there is quite a bit of code here, but we really only care about the last line (that assigns to the People property of the ViewModel). The rest is plumbing.
Compare this to using a DelegateCommand from the Prism framework:
This allows us to do the same thing (assign a value to the People property), but we can do this with just one line of code (the DelegateCommand constructor) instead of needing to create a custom class. The parameter of the DelegateCommand constructor is the "Execute" we want to perform ("Execute" is part of the ICommand interface).
ICommand has another method: "CanExecute". This returns true or false depending on whether the command can be executed. In our example, this always returns "true". But sometimes this is more complicated -- such as if we need to check a property or run some code. The DelegateCommand constructor takes a second parameter which is a delegate for "CanExecute". If you do not provide one, then "CanExecute" is always true.
As you can see, DelegateCommand makes our code much more compact. And if we don't want to use a lambda expression (or if our Execute is several lines of code), then we can use a standard delegate method instead. The result is that it is easier to see the intent of our code. Instead of looking through a custom command object for the Execute method, we have the code right here in the constructor (or a pointer to it in the case of a named delegate).
When you have a number of commands in the application, this makes a huge difference in the amount of code that needs to be written as well as the readability of that code.
NotificationObject
NotificationObject is another class that is provided by the Prism framework. This class implements the INotifyPropertyChanged interface. This interface needs to be implemented in order for data binding to work as expected in XAML. The interface itself is not hard to implement (just a few lines of boiler-plate code). The difference between NotificationObject and manual implementation has to do with the RaisePropertyChanged methods that are available.
When implementing INotifyPropertyChanged, you generally make a call to RaisePropertyChanged in the setter for a Property, such as this:
The RaisePropertyChanged method will alert the UI that the underlying property has been updated and that the UI should refresh the binding. Notice that this version of RaisePropertyChanged takes a string parameter.
In contrast, NotificationObject provides a RaisePropertyChanged method that takes an Expression. This lets us write code like this:
Your first thought might be, "I don't see much of a difference." But there is. Instead of using a string, we use an expression with the actual Property. This means that we get IntelliSense when we are creating this method. It also means we will get a compiler error if we type the property name incorrectly. And most importantly, if we rename our property, our refactoring tools will automatically update the RaisePropertyChanged method as well. Using properties over strings is definitely the way to go.
Nothing You Can't Do Yourself
I had an interesting conversation with someone about Prism. He asked me what I liked about it, and I told him that I really liked the DelegateCommand. His response was that you could create a DelegateCommand object yourself -- it's only about 15 lines of code. And he is absolutely correct.
Prism doesn't perform any magic. It consists of a set of helper classes and methods that you could implement yourself. But we don't have to. The Patterns & Practices team has implemented these for us and put them together in a package that is easy to use.
If you don't like any of the implementations, you are free to change them. Prism comes with all of the source code (including unit tests). So you can enhance or re-implement any of the features. My experience is that the features are well-implemented and have met my needs.
What About Windows 8?
My one disappointment around Prism is that it looks like there won't be an implementation for Windows Store Applications. Prism covers a lot of platforms: WPF, Silverlight 5, and Windows Phone 7.5. The latest rumors are that there will be a different guidance package from the Patterns & Practices team for Windows Store Applications, and I have not been able to hunt down a beta or a release date at this point.
If you are developing Windows 8 desktop application with WPF, then Prism will work just fine. But for Windows Store Applications, we will need to wait for another solution.
[UPDATE: There has been announcement regarding guidance for Windows Store Apps. More info: Update on Windows 8 Guidance]
Wrap Up
As I mentioned, my opinion of Prism has not changed much from my initial impressions of working with it. It has been a very good framework for my current project, and I will keep it in mind for future projects. If you are working on fairly straight-forward applications or applications with just a few screens, then Prism may be more than you need. But if you are working on modular or enterprise-level applications, it may be just what the doctor ordered.
Happy Coding!
Book Review: Professional .NET Framework 2.0
So, I'm a bit behind on commenting on the tech books that I've read recently. The first is Professional .NET Framework 2.0 by Joe Duffy (Amazon link). Note: this book is from 2006 and is currently out-of-print; fortunately there are several sellers in the Amazon marketplace how have new or used copies.
Now, it may seem strange to be reading a .NET 2.0 book from 2006 in 2012, and I would normally agree with that thought. But this book has a few key advantages to some others. It was recommended to me as a way to "fill in some gaps", and it has done just that. I'm not really going to review the entire book here, just provide some comments and samples on what made this valuable to me.
Big Plus - Joe Duffy
One of the big advantages to this book is its author. Joe Duffy was a program manager on the CLR (Common Language Runtime) team at Microsoft. This means that he knows the internals of the CLR and not just the external APIs. And this book provides plenty of insight into the internals, as we'll soon see.
Looking into IL
The biggest learning that I took away from this book is a better understanding of IL (Intermediate Language). This is what the compiler generates from your C# or VB.NET code (or any other .NET language). It is not machine code, but it has more in common with assembly language than a 3G or 4G language that business programmers generally use. The IL will get Just-In-Time compiled (jitted) to the instructions that the machine will actually run.
Now, I've known about IL for a long time, and I've seen people who look at it. Historically, I haven't been one to dig into it myself. But after having Joe Duffy explain IL and how language components get transformed into IL, I've been more interested in digging into the IL to see how things are generated.
Setting up ILDASM
The .NET SDK ships with a way to look at the IL -- this is ildasm.exe (for IL Disassembler). Here's where it's found on my 64-bit machine:
At this location, you'll find a file called "ildasm.exe". You can run this directly, and then use the File -> Open dialog to locate a .NET assembly. But what's even better is to add this as an External Tool in Visual Studio. Then you can just run it against whatever project you're currently working on.
To configure this in Visual Studio (I'm using VS2012, but it's the same in earlier versions), just go to the "Tools" menu and select "External Tools...". From here, you can Add a new tool. When you're done, it should look something like this:
For the Title, you can use whatever you'd like; this is just what will appear on the Tools menu. The command should be the fully-qualified location of the "ildasm.exe" file.
The "Arguments" and "Initial directory" settings are a little more interesting. Notice the arrow to the right of the text box. This gives you a number of variables that you can choose from. For the "Arguments" property, I chose 2 variables. The first "$(TargetName)" is the name of the assembly that is currently active. Note that this does not include the file extension, just the name. Because of this, we also need "$(TargetExt)". This will give us ".exe" or ".dll" depending on what type of assembly we are building.
The "Initial directory" setting tells us where the assembly (from the argument) is located. In this case, "$(TargetDir)" means the output location of the file. So, if we are in the Debug build, it will be "<project path>\bin\Debug\".
After clicking "OK", we now have a new item on our tools menu.
Using ILDASM
So, now that we have Visual Studio configured so that it's easy to get to ildasm, let's see what this looks like. I created a very simple console application that just outputs "Hello, World!" (using Console.WriteLine). I don't think I need to reproduce the code here ;-)
With this project open, I just need to go to Tools -> ILDasm, and it opens up the compiled assembly. Drilling down a bit, we get to the Main method:
The name of my application is "ILDamsTest.exe", and we traverse the tree to get to the Main method. If we double-click on the Main method, we get to the disassembled IL:
Here, we see the IL for the most basic console application. Going through the instructions, we have the following. First, "nop" is a "no op", meaning no operation is performed. This is here so that the compiler can attach a breakpoint to a part of the code that doesn't perform an operation (for example, attaching a breakpoint to the opening curly-brace of the method).
Next, we have "ldstr" which loads the string "Hello, World!" onto the stack. Next, we have a "call" that runs the Console.WriteLine method. Note that the IL has the fully-qualified name for this, including the assembly (mscorlib) and the namespace (System). We can see that this method takes a string argument, and it gets this from the top of the stack. Since we just pushed "Hello, World!" onto the stack, this string will be used for the parameter.
Next we have another "nop", for the closing curly-brace, and finally the "ret" that returns from the method.
Pretty simple. Now let's look at the same thing compiled in "Release" mode:
Notice that we've gone from 5 instructions down to 3; the "nop" instructions are gone. The compiler removed them since we can't breakpoint into release code.
More Fun with IL
So, after I started looking just a little bit at IL, I've become much more curious about how the compiler generates IL. For example, I like to see what code is generated by the "shortcuts" that the C# language and compiler give us.
Here are 2 equivalent blocks of code:
Now, the "foreach" loop will work on any object that implements the IEnumerable interface. That interface has a single method ("GetEnumerator"). (Note: if you want more information on IEnumerable, you can reference the series of articles at Next, Please! A Closer Look at IEnumerable.)
So, the first block of code shows how to use the Enumerator directly (with MoveNext and Current), and the second uses the "foreach" construct. We would expect that these two blocks would compile to the same IL.
But if we look at the IL, we find that they are not compiled to the same code. They are close, but when "foreach" is compiled, it is automatically wrapped in a try/finally block. Try this yourself to see.
And so started my journey into IL and the fun behind it. Some other interesting places to look include anonymous types (to see that the compiler does create a type with an internal name), delegates (to see what a delegate is behind the scenes), lambda expressions, and many others. You will probably come across some compiler optimizations that surprise you as well.
Note: I won't include any links to IL references because I haven't found any good ones. If you want the specification, you can search for "ECMA 335", with a caveat that this is the 500+ page specification document (not overly readable). Professional .NET Framework 2.0 provides a compact reference for IL (along with a number of examples).
[Update: I found an online reference. It's not very descriptive, but it has the CIL Instructions: http://www.en.csharp-online.net/CIL_Instruction_Set.]
Wrap Up
So, even though Professional .NET Framework 2.0 is 6 years old, I found many useful things in it. There are plenty of good topics (including a look at the Garbage Collector and also multi-threading). As you can probably tell, I've become comfortable looking at the IL -- something that I never would have done before. An appendix is dedicated to the IL operations so that you can parse the output of ildasm yourself. Once you start looking at the IL, you come across all sorts of interesting things that will give you a better understanding of how the code you write gets transformed into something closer to what the machine will actually run.
This is not a resource for a beginner or someone new to C#, but it is a great way to take a deeper dive into some of the fundamentals of the .NET Framework.
Happy Coding!
Now, it may seem strange to be reading a .NET 2.0 book from 2006 in 2012, and I would normally agree with that thought. But this book has a few key advantages to some others. It was recommended to me as a way to "fill in some gaps", and it has done just that. I'm not really going to review the entire book here, just provide some comments and samples on what made this valuable to me.
Big Plus - Joe Duffy
One of the big advantages to this book is its author. Joe Duffy was a program manager on the CLR (Common Language Runtime) team at Microsoft. This means that he knows the internals of the CLR and not just the external APIs. And this book provides plenty of insight into the internals, as we'll soon see.
Looking into IL
The biggest learning that I took away from this book is a better understanding of IL (Intermediate Language). This is what the compiler generates from your C# or VB.NET code (or any other .NET language). It is not machine code, but it has more in common with assembly language than a 3G or 4G language that business programmers generally use. The IL will get Just-In-Time compiled (jitted) to the instructions that the machine will actually run.
Now, I've known about IL for a long time, and I've seen people who look at it. Historically, I haven't been one to dig into it myself. But after having Joe Duffy explain IL and how language components get transformed into IL, I've been more interested in digging into the IL to see how things are generated.
Setting up ILDASM
The .NET SDK ships with a way to look at the IL -- this is ildasm.exe (for IL Disassembler). Here's where it's found on my 64-bit machine:
At this location, you'll find a file called "ildasm.exe". You can run this directly, and then use the File -> Open dialog to locate a .NET assembly. But what's even better is to add this as an External Tool in Visual Studio. Then you can just run it against whatever project you're currently working on.
To configure this in Visual Studio (I'm using VS2012, but it's the same in earlier versions), just go to the "Tools" menu and select "External Tools...". From here, you can Add a new tool. When you're done, it should look something like this:
For the Title, you can use whatever you'd like; this is just what will appear on the Tools menu. The command should be the fully-qualified location of the "ildasm.exe" file.
The "Arguments" and "Initial directory" settings are a little more interesting. Notice the arrow to the right of the text box. This gives you a number of variables that you can choose from. For the "Arguments" property, I chose 2 variables. The first "$(TargetName)" is the name of the assembly that is currently active. Note that this does not include the file extension, just the name. Because of this, we also need "$(TargetExt)". This will give us ".exe" or ".dll" depending on what type of assembly we are building.
The "Initial directory" setting tells us where the assembly (from the argument) is located. In this case, "$(TargetDir)" means the output location of the file. So, if we are in the Debug build, it will be "<project path>\bin\Debug\".
After clicking "OK", we now have a new item on our tools menu.
Using ILDASM
So, now that we have Visual Studio configured so that it's easy to get to ildasm, let's see what this looks like. I created a very simple console application that just outputs "Hello, World!" (using Console.WriteLine). I don't think I need to reproduce the code here ;-)
With this project open, I just need to go to Tools -> ILDasm, and it opens up the compiled assembly. Drilling down a bit, we get to the Main method:
The name of my application is "ILDamsTest.exe", and we traverse the tree to get to the Main method. If we double-click on the Main method, we get to the disassembled IL:
Here, we see the IL for the most basic console application. Going through the instructions, we have the following. First, "nop" is a "no op", meaning no operation is performed. This is here so that the compiler can attach a breakpoint to a part of the code that doesn't perform an operation (for example, attaching a breakpoint to the opening curly-brace of the method).
Next, we have "ldstr" which loads the string "Hello, World!" onto the stack. Next, we have a "call" that runs the Console.WriteLine method. Note that the IL has the fully-qualified name for this, including the assembly (mscorlib) and the namespace (System). We can see that this method takes a string argument, and it gets this from the top of the stack. Since we just pushed "Hello, World!" onto the stack, this string will be used for the parameter.
Next we have another "nop", for the closing curly-brace, and finally the "ret" that returns from the method.
Pretty simple. Now let's look at the same thing compiled in "Release" mode:
Notice that we've gone from 5 instructions down to 3; the "nop" instructions are gone. The compiler removed them since we can't breakpoint into release code.
More Fun with IL
So, after I started looking just a little bit at IL, I've become much more curious about how the compiler generates IL. For example, I like to see what code is generated by the "shortcuts" that the C# language and compiler give us.
Here are 2 equivalent blocks of code:
Now, the "foreach" loop will work on any object that implements the IEnumerable interface. That interface has a single method ("GetEnumerator"). (Note: if you want more information on IEnumerable, you can reference the series of articles at Next, Please! A Closer Look at IEnumerable.)
So, the first block of code shows how to use the Enumerator directly (with MoveNext and Current), and the second uses the "foreach" construct. We would expect that these two blocks would compile to the same IL.
But if we look at the IL, we find that they are not compiled to the same code. They are close, but when "foreach" is compiled, it is automatically wrapped in a try/finally block. Try this yourself to see.
And so started my journey into IL and the fun behind it. Some other interesting places to look include anonymous types (to see that the compiler does create a type with an internal name), delegates (to see what a delegate is behind the scenes), lambda expressions, and many others. You will probably come across some compiler optimizations that surprise you as well.
Note: I won't include any links to IL references because I haven't found any good ones. If you want the specification, you can search for "ECMA 335", with a caveat that this is the 500+ page specification document (not overly readable). Professional .NET Framework 2.0 provides a compact reference for IL (along with a number of examples).
[Update: I found an online reference. It's not very descriptive, but it has the CIL Instructions: http://www.en.csharp-online.net/CIL_Instruction_Set.]
Wrap Up
So, even though Professional .NET Framework 2.0 is 6 years old, I found many useful things in it. There are plenty of good topics (including a look at the Garbage Collector and also multi-threading). As you can probably tell, I've become comfortable looking at the IL -- something that I never would have done before. An appendix is dedicated to the IL operations so that you can parse the output of ildasm yourself. Once you start looking at the IL, you come across all sorts of interesting things that will give you a better understanding of how the code you write gets transformed into something closer to what the machine will actually run.
This is not a resource for a beginner or someone new to C#, but it is a great way to take a deeper dive into some of the fundamentals of the .NET Framework.
Happy Coding!
Subscribe to:
Posts (Atom)