Visual Studio

Ctrl + Alt + E - The Way to Debug for Me

Rick G. Garibay - The more I learn, the less I kno — Fri, 05 Oct 2007 20:22:22 GMT

One of the best things I love about consulting is how much I learn from my clients.

I have been in out in Salt Lake City for the last few weeks working on a WCF SOA project for a client and have been stepping through lots of code. And I'm not just talking about regular .NET code either- I'm talking two instances of Visual Studio 2005 up and running, one exercising a test harness/unit test and the other hosting a WCF service. I love the ability to step through a client, watch the call cross the process boundary and step into the service code. Visual Studio 2005 is truly a marvel of an IDE!

One of the things I learned from the lead .NET developer (Sam "Samwise" Walker) this week is that VS 2005 supports the ability to control how the debugger interacts with exceptions. I have always debugged as follows:

1. Step through the code
2. If an exception is thrown, the debugger chokes at the top-most level in the call chain
3. I then trace the exception back to the original site

This approach is ardous because by default the debugger will capture unhandled exceptions, but since exceptions bubble up to the top of the call stack, you are always left dealing with the outer exception.

The solution is to set VS 2005 up to intercept exceptions as they are thrown, the first time an exception is thrown. This is contrary to the default behavior where the debugger will only catch the last unhandled exception as it winds it's way up the call stack.

To enable this feature, in VS 2005, click Ctrl + Alt + E. An Exceptions window will appear. You will notice that for "Common Language Runtime Exceptions", the right-most column, "User Unhandled" is checked. This is the default behavior. Click the checkbox next to "Common Language Runtime Exceptions" labeled "Thrown". From this point forward, you will capture the very first exception as it is initially thrown.

Hopefully, this tip will save you some time in your next debugging session.

Thanks Sam!

MSBuild Reference Paths

Rick G. Garibay - The more I learn, the less I kno — Sat, 25 Aug 2007 22:50:22 GMT

One of the nice things about MSBuild is that with Visual Studio 2005, the project and solution files are the build files. So, in theory, MSBUILD will start at the sln file and walk all references during a build process.

But, what happens when you have an automated build process, or are doing continous integration and want to standardize project references to assemblies and other vendor components? Trying to get an entire development on board to use specific paths, etc is an option, but since no one is perfect (and enforcing these rules can be a nightmare), we need a better way to standardize the management of how dependancies are accessed.

With a build process in place, the build can facilitate this standardization. Assemblies, both internal and from external vendors can be catalogued on a file share and the build process itself can reference this shared location in a standardized manner, without trying to micro-manage development environment settings.

The solution is to use the ReferencePath property at the MSBUIILD command line.

For example:

MSBUILD.EXE <solution name> /p:"ReferencePath=<Path1;Path2;Path3>"

The ReferencePath property allows you to add a series of paths that MSBUILD will check, overriding any project-based references.

This is extremely helpful when references are all over the place or when it is undesirable to recreate development-time configuration at build time.

Visual Studio 2008

Rick G. Garibay - The more I learn, the less I kno — Thu, 19 Jul 2007 00:44:14 GMT

Looks like the next version of Visual Studio, code named Orcas will ship in February along with .NET FX 3.5:

"The next version of Visual Studio, Microsoft Visual Studio 2008 (formerly known as Microsoft Visual Studio code name "Orcas"), will provide a developer experience for Windows Vista, the 2007 Microsoft Office system, and the Web. To enable early feedback, Microsoft provides Community Technology Preview (CTP) and Beta releases of Visual Studio 2008. Get an early look at Visual Studio 2008 Beta 1 and check back for the late-summer Beta 2 release."

-MSDN

What does this mean? For one, if you are working with .NET 3.0, you will now have a fully integrated development environment with full support for WCF, WPF and WF templates out of the box.

It also brings the following "red bits" features back into the main product, including ASP.NET AJAX and the Web Application Project template.

If you are doing WCF, a number of new serialization and messaging features will be added including:

AJAX,
JSON,
REST
POX
RSS
ATOM

LINQ is also a big one which will change how we do DAL development. Unlike .NET 3.0, .NET 3.5 introduces a change to the C# compiler and a new CLR which will definetely make the development and deployment experience interesting...

Making Configuration Files Available to NUnit

Rick G. Garibay — Wed, 21 Mar 2007 21:07:43 GMT

NUnit can be run against any type of portable executable (PE), including DLLs and EXEs.

Often, you will need the test that is calling a component to behave as if it itself were the actual call site, meaning that any configuration settings that will be in effect at deployment time should take effect during testing as well. For EXE based assemblies, this is a trivial issue- simply add an app.config to the test project in Visual Studio and away you go.

When unit testing non-executable assemblies (DLLs), however, this isn't as straighforward because DLLs cannot execute without a host process. In this case, take the app.config you created and copy it into the bin directory in which the assembly you are testing is loaded. Rename the app.config to the full name of the assembly that NUnit will load.

For example, for an assembly called "Ess.ServiceGateways.Epm.Interop.dll", you would rename the app.config to "Ess.ServiceGateways.Epm.Interop.dll.config".

NUnit will probe for a configuration file with the same name of the assembly hosting the tests and load the configuration accordingly.

When All Else Fails, Try MSIEXEC

Rick G. Garibay — Sat, 17 Feb 2007 16:11:09 GMT

If anyone has had the misfortune of installing the Whidbey (VS.NET 2005) bits along with .NET FX 2.0 or any of the Express betas, you may find that you cannot uninstall using 'Add Remove Programs'.

In my case, I installed .NET FX 2.0 along with C# and Web Express side by side with VS.NET 2003, and when I tried to uninstall it, I found that I couldn't.

This pales in comparison to other posts I've seen where installing the beta bits hosed current installs of VS.NET 2003, but more common is an issue when trying to install newer builds of Whidbey ontop of an existing build. Microsoft recommends uninstalling all old versions before installing a new version, but many, like me, found that uninstallation is not trivial.

When trying to uninstall any of the above, I was getting error messages indicating that the action was prohibited by group policy. Since there are no GPO on my machine that care what gets uninstalled, this message is bogus. That said, the problem of getting rid of the installs remained.

The solution:

The solution comes down to two very useful utilities, msiexec and msiinv (sorry, you'll actually have to keep reading to find out how to get this). The former comes with the Microsoft Platform SDK, but the latter, unfortunately is only distributed on a case-by-case basis by Microsoft.

Msiexec simply calls the uninstaller, passes it an MSI package name or a product code, which is a GUID that uniquely identifies the product. All products have this GUID, but as I found out, determining the GUID for each product is not trivial.

Anyway, the syntax for msiexec is:

Msiexec /x {GUID} | PackageName.msi

Note the pipe "|" above is used to specify OR.

So, if I were to uninstall the Whidbey bits, per Sam Gentile's blog, you would issue the following command:

msiexec.exe /x {B3A02601-8FE9-4108-8E95-D94171A2F8C8}

Why that works, but 'Add/Remove Programs' doesn't, or using the PackageName.msi option does not, I don't know. If anyone does, please let me know.

BUT, what if you need to uninstall a product for which you do not know the GUID/Product Code? Enter msiinv.exe.

As the name impiles, msiinv does an inventory of all msi packages on your machine, and reports them to a txt file of your choosing. So, to pipe the results from your machine, simply issue the following command and the command prompt:

Msiinv.exe > MyTextFile.txt

You now will have a GUID for every product on your machine, and you *should* be able to remove it.

As I mentioned before, msiinv.exe is only distributed by Microsoft on a case by case basis, meaning that you actually have to open up an email dialogue with a Microsoft rep. Some very dedicated searching on the boards finally got me this little gem.

To save you the time and effort, I am providing the link here, although I can't guarantee that it will always be available, nor do I make any guarantees that the file is safe although I did download it and have used it without issue.

Note: My intention was to provide the utility for download, but after following up with a contact at Microsoft, I thought better.Why the hell don't you just host the file yourself you ask? Well, from my a moral gray area, I believe it is one thing to actually host the binaries and quite another to merely provide a shortcut to freely accessible information.

Happy Programming!

** There is another utility called msizap that is supposed to perform a rudimentary removal if msiexec fails. Fortunately, I never had to use it.