Some cool tools
Jeff Key has some interesting tools available here:
http://www.sliver.com/dotnet/index.aspx
Show GAC Detail
The GAC view in Windows Explorer ususally shows a special view instead of all the real subdirectories you can see if you go to the DOS prompt. With a little registry tweak, you can use Windows Explorer to navigate the GAC.
The following registry script will change the GAC view to detail. Put it in a file and end it with .reg:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]"DisableCacheViewer"=dword:00000001To restore it to the normal GAC view, just change the value back to 0:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"DisableCacheViewer"=dword:00000000
Moving from VB.Net to C#
[There's some interesting threading stuff further down if you want to skip the first couple of paragraphs about my C# preference]
At the end of last year, we officially switched to all new development in C# instead of VB.Net (to the cheers of many of us on the team who are quite experienced with C#).
We converted some code to C#. We found the C# code executes faster and is more compact. While I'm not that crazy about VB.Net, it's usable and you can do some real stuff in it (I never did like VB6). What I really admire, though, is the VB.Net compiler.
When converting to C#, we realized what amazing things the VB.Net compiler does--and what garbage code existed in some places in our system. The VB.Net compiler is very forgiving and takes what you give it and figures out what's really needed under the hood. Pretty cool stuff, but it does add overhead to your code.
Threading IssuesWe ran into a real interesting gotcha recently that had to do with threading. We have a VB.Net console application. When it ran, it was causing all sorts of memory problems. The production application actually threw out of memory exceptions. It was driving us nuts. This application doesn't use that much memory. It does run in a loop.
Occasionally when in the debugger, we'd get some interesting COM exceptions complaining about a Context Switch Deadlock. I've seen this before and was kind of surprised, since the app I was debugging was 100% managed code.
Someone on the team tracked down this article:
http://msdn2.microsoft.com/en-us/library/ms172233.aspxIt's quite interesting. Microsoft by default assumes that a VB.Net console application should run as an STA. Our console application was multithreaded. However, it wasn't really running this way because under the hood, VB.Net adds a STAThreadAttribute to your console application. This is more of Microsoft VB's "hide programming from the programmer" attitude that I don't like. Why on earth should it default a .Net managed application to STA just because it's in VB?
The solution to our problem was to add the MTAThreadAttribute to our application and all ran well. No more memory problems.
Because it was STA, the message pump wasn't running. That meant that the garbage collector wasn't able to free some things. I'm glad it's fixed now. I just wish that Microsoft would not hide such details. Even if there is a good reason for VB.Net console applications to default to STA, put the attribute in the code where we can see it; don't just have the compiler insert it.
Choose default editor for file type in VS2005
I've been working with WPF/XAML and ran across a post today that told me how to do something useful in VS: choose the default editor for a file type.
Suppose the default editor is the graphical editor and you want it to open code view. All you have to do it right click on the item in Solution Explorer. Choose Open With. A dialog appears and you can select an item and make it the default!
Exceptions, all the way down to SEH
A good article on the internals of exceptions, including CLR, C++, and Windows SEH:
http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx
Scott's Blog ASP.Net VS2005
I've found some good stuff on Scott's blog regaring all the fun we're having with VS2005 and web projects.
Here's his blog:
http://weblogs.asp.net/scottgu/One thing Scott's pointed us to is the web deployment projects add-in:
http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspxThere's also interesting stuff about web projects in 2005:
http://weblogs.asp.net/scottgu/archive/2005/12/16.aspxhttp://webproject.scottgu.com/We've got to try this out. The original "site" model with 2005 just messes up everything for us. It's like they never thought anyone would put something through a build process.
NGEN
I wasn't aware of NGEN. I stumbled across it today. Here's a great article on .Net 1.1 and 2.0 NGEN:
http://community.bartdesmet.net/blogs/bart/archive/2005/09/01/3512.aspxYou can also see an MSDN Magazine article about it:
http://msdn.microsoft.com/msdnmag/issues/05/04/NGen/default.aspx
