Category Archives: visual studio 2008

Setup project with COM library installation (Visual Studio)

Today at work I had a requirement on a setup that a certain COM library should be registered on application setup. Browsing the internet for a solution, I found the next information at MSDN (just copied here to prevent it from being lost :) ):

Steps to Register a COM Module in a Visual Studio .Net Deployment Project

  1. Add a COM object to your Visual Studio deployment project.
  2. In the Solution Explorer, right-click the module that you just added, and then click Properties.
    NOTE: The Properties window contains a table with two columns and x number of rows (the number of rows depends on the project). The left column lists the specific properties. The right column is explained in step 4.
  3. Go to Properties for this module (located by default in the upper-right corner of the .NET Deployment project), and then click Registry property.
    NOTE: The Registry property specifies whether a file, assembly, or project output group should be registered on a target computer during installation.
  4. There is a list box in the right column of the Registry property, which displays several options for you to choose from. Note the following details for an explanation of these options:
  • For assembly, registration is not normally required, and therefore the default is DoNotRegister (this means that the item will not be registered during the installation).
  • For a COM module, you have the options of COM, COMRelativePath, and COMSelfReg. Any one of those three options will register the COM module during the installation.

Note the following details about each choice:

  • COM: The module will be registered as a COM object by the Windows Installer engine. The deployment project will update the Class table, ProgID table, and other tables in the Registry Tables group of the corresponding .msi file. This is the recommended way to register a COM module.
  • COMRelativePath: The module will be registered as an isolated COM object by the Windows Installer engine. Note that this module will be used only by the application that the module is installed with.
  • COMSelfReg: The installer calls the DllRegisterServer function of that module at the time that you install the module and the DllUnregisterServer function at the time that you uninstall the module. The deployment project will update the SelfReg table of the corresponding .msi file. It is not recommended that the installation package use self-registration. Instead, the installation package should register modules by authoring one or more of the other tables provided by the installer for this purpose (that is, select the COM or COMRelativePath options). Many of the benefits of having a central installer service are lost with self-registration, because self-registration routines tend to hide critical configuration information.

You can now build your deployment project to allow the preceding modifications to register your COM objects in accordance with the registration property options that you selected in step 4.

Although it sounds frustrating, using this information, registering COM libraries at application setup is quite easy!

Happy coding!

The using statement and XmlReader.Create

Are you also fond of using the using statement (e.g. when dealing with streams)? I am, since it kind-of guarantees me that streams are closed when I think they should be closed, even if I do not specify the Dispose() command. You probably noticed the ‘kind-of guarantee’ part. You are right, this is not always the case. It took me a while to find out the the following is not going to work as smooth as expected:

using (var reader = XmlReader.Create(File.Open(fileName, FileMode.Open)))
    { ... }

You probably wonder what’s the problem of the code printed above. I don’t see it too, however, I know there is a problem related to this code. The problem lies in the Create overload used in the example code. It uses default XmlReaderSettings. Unfortunately, this settings do not include having the CloseInput property set to true. You can do the math: no closed file at all! That’s a guarantee for having troubles on the file ‘being in use already’.

The solution to this problem is quite simple:

using (XmlReader reader = XmlReader.Create(File.Open(path, FileMode.Open),
         new XmlReaderSettings { CloseInput = true })) { ... }

How can we call this? A ‘bug’? No, at least not technically spoken. Since the XmlReader creates the stream, it should close it too. The case is, you should not expext it knowing the using statement as most people know it (fail-proofing your code). Since I know this, I am a little bit scared about using using statements without calling the stream’s constructor. You can do so, but be sure it does what you expect it to do… In my opinion, the using statement still remains very helpful, please I do not consider it being as perfect as I thought it to be for years ;) …

Solution: The operation could not be completed. Invalid FORMATETC structure

This morning I ran into a ASP.NET bug in Visual Studio. Dragging a custom server control on an aspx file was not possible since I had ‘an invalid FORMATETC structure’ (what the …. is that?!). The message box alerting me something is really really wrong is this one:

The FORMATETC bug

Trying to solve the bug, I  found the following attribute to be the problem: [ToolboxItem(true)]. Just delete the attribute, rebuild the application and the problem/bug disappears!

Good luck! Happy coding!

How to detect installed CLR versions and how they are used…

It has been a while since I posted anything on my blog. Sorry for keeping you on hold ;) ! I think the blog will be filled with some information shortly, since I am still overthinking all the great stuff I saw on Tech-Ed North America a couple of weeks ago (first I had to overcome the jetlag, then the weather in The Netherlands, etc. etc. :) ). Enough nonsense for now!

While attending a session by Scott Hanselman on everything new in .NET 4.0 he showed a wonderful small tip, not only useful for the few of us already working on Visual Studio 2010: when working in the VS.NET Command Prompt, there is a small but useful command called ‘CLRVER’. It shows all .NET versions installed on your computer. Also, as an addition to this command, you can show active runtime processes using the -all switch. Nice piece of code! Enjoy!

Delete workspace from no longer existing TFS

A week ago I started to use a new TFS server (TFS 2008). The old TFS server got phased out yesterday after moving all sources to the new TFS server. Doesn’t sound like a problem, does it? However, I forgot to remember my laptop: my old workspace was still in there, but to delete a workspace the normal way the TFS server should be available. At itself, this is still not much of a problem, however: when you would like to map your new source control folders to the old ones on disk, this is not possible since the old workspace is still mapped to that location. Arghhh!!!

Luckily, there is a tf.exe command tool switch (discussed a few minutes ago in my previous blog post) to cope with this problem: use ‘tf workspaces /remove:*’ and all cached workspaces will be gone! Problem solved!