Inner Drive Software

I'm living a geek dream: I've found a confirmed bug (reg.req.) in Microsoft Visual Studio 2005.

The defect is a little hard to explain, so bear with me. When you create an international application, you need to separate all of the text messages from the program itself. You do this by putting them in resource files, which the compiler merges with the code. You can have any number of resource files, one for each language and culture you want to support, as long as you have at least one "neutral" resource file (which, for us, is always U.S. English). (To see how this works, check out our measurement demo on the Inner Drive main site.)

Now, Visual Studio 2005 allows you to put your source code files into any arrangement of folders you want within a project, so you can organize the project better. For example, our measurement demo uses about 150 C# class files, which we've organized into a several subfolders under the project folder: Measurements, Units, etc.

You also need to know that there are two kinds of objects in the .NET universe: classes and structures. (For more information about this, read the .NET programmer's guide.) They behave very differently under the hood, but as far as the resource compiler is concerned, they're indistinguishable.

Well, not really. I discovered that Visual Studio has a problem compiling the resources of a structure within a subfolder.

Here's how to reproduce this problem for yourself:

1. In Visual Studio 2005, create a new C# Class Library project.
2. Add a subfolder called "Folder" to the project.
3. Add a class file to the subfolder called "MyClass.cs".
4. In the class file, define the class as an empty public struct (rather than a public class) in the Namespace namespace.
5. Add a string resource file to the subfolder called "MyClass.resx". Visual Studio should link the resource file to the class file.
6. Delete the resource designer file, if Visual Studio creates it.
7. Add a string to the resource file.
8. Compile and link.

Now examine the project's obj folder. You will see that the resources .dll is called "Namespace.Folder.Class.resources". If you examine the bin folder and look at Namespace.dll using ILDAsm.exe, you'll see that the assembly refers to Namespace.Folder.Class.resources as well.

Now change the struct to a class, still in the Namespace namespace, and recompile. The obj folder will now contain "Namespace.Class.resources", and the assembly will refer, correctly, to Namespace.Class.resources as well.

I've put together an example of this problem that you can download: VSBug268071.zip (25.44 KB).

The workaround, for now, is either not to put the struct files into subfolders, or to change the structs to classes. Generally we're doing the former, as we're pretty careful about our struct-vs.-class decisions in specific, and we don't want our design choices usurped by the IDE in general.