"Location is not available" on Vista

Ok, this is not exactly a .NET issue but I still thought it is worth mentioning it here since I assume there is a sufficient number of people currently using Vista for development who may have encountered this issue. You may have experienced one or more of the following:

• "Preparing your desktop..." for an extended period of time
• "Location is not available" after you log in
• Desktop looks more like XP and has lost the Aero look-and-feel

I don't know what the reason for this was. Maybe it was relating to my Vodem to not being able to survive stand-by and/or hibernate. Maybe it was because Vista decided to run some lengthy checks, like CHKDSK. The event logs don't give a clue.

Resolution: Reboot another time.

csUnit 2.3 available

Just in case you are a regular reader of this blog: csUnit 2.3 has just been made available. With this release we have focused on improving the quality by fixing a few defects. On behalf of the csUnit team: Happy testing!

unresolved external symbol ?.cctor@@$$FYMXXZ

This error is usually related to upgrading Managed C++ project from Visual Studio 2003 to Visual Studio 2005. It is easy to resolve by removing a few options from both the compiler and linker, then recompiling the project. For the compiler remove the /ZI flag (don't confuse with /Zi). In the project properties pages choose "Configuration Properties", then "C/C++", then "Command Line". In the bottom part of the page you'll see "Additional Options". Remove /ZI from there if you have it at all. Next, go to "Linker", then "Command Line". Remove /NOENTRY and /NODEFAULTLIB from there if you have it at all. In all cases make sure you do this for all configurations not just the debug or the release configuration. More details about the context and background are available here.

csUnit, Visual Studio 2008, Vista, .NET 3.x

Maybe you have wondered about whether csUnit is supported on Vista and/or Visual Studio 2008. So in this post I'd like to give a few details for csUnit 2.2. Microsoft Windows Vista is not an issue. csUnit installs and runs just fine. This is also true for Visual Studio 2005 on Vista. The add-in registers properly and the context menus work, too. Visual Studio 2008 is a different story. The add-ins don't install and neither do the context menus. This is an item that we'll address in one of the next csUnit releases. If you are building for .NET 2.0 in VS 2008 you can still use csUnitRunner as a stand-alone application and run all tests. This mode works on both XP and Vista. If you are building an application for .NET 3.0 or .NET 3.5 that's fine, too. Simply include the reference to the csUnit 2.2 runtime assemblies as before and run your tests within csUnitRunner (or the add-in in VS 2005 if you managed to modify VS2005 to use .NET 3.x). If you encounter an issue with any of the above combinations, or if you find a combination that doesn't work, we would be very interested to hear about it. Please log a bug report at csUnit's but tracker at SourceForge and include as many details about your specific configuration as possible. Happy testing! (Note: All of the tests mentioned above were conducted using the English language version of the mentioned software components, all of them on the latest patch level as of the date of publication.)

csUnit Sources About To Be Moved to Subversion

Since the beginning csUnit has used Sourceforge's CVS repository. In the meantime Subversion has become very stable and provides a number of benefits over CVS. As a consequence we will stop using the CVS repository. All committed source code that was available in CVS will continue to be available via CVS. Access is also possible via the internet and ViewVC. As of the conversion date all new commits will go into the Subversion repository. We have no plans to migrate old commits to the new repository. Details for accessing the new repository are available here.

Visual Studio: "Unable to find manifest signing certificate in the certificate store"

I just moved a Visual Studio project from one computer to a different one. When I then tried to rebuild the solution I received the following error:

"Unable to find manifest signing certificate in the certificate store"

As I was sure that I wasn't using any certificate to sign the assembly I couldn't understand the reason for this error message and the integrated help system for Visual Studio wasn't a big help either. It turned out that I had to manually go into the *.csproj file and remove the following three lines that were apparently left over from some past experiments with signing using a certificate:

<manifestcertificatethumbprint>...</manifestcertificatethumbprint> <manifestkeyfile>...</manifestkeyfile> <generatemanifests>...</generatemanifests> <signmanifests>...</signmanifests>

After I had removed those lines I reloaded the project and the solution rebuilt just fine. There is more information on this subject at a Microsoft Forum.

const == static?

Sometimes it can be the simple things that surprise. Ok, maybe you are one of those geniuses who knew it all the time. If that is the case don't bother reading this post. For all mere mortals go ahead. When writing code in C# on the surface you would assume that const and static mean two different things. But in reality there is a connection. As soon as you declare a field to be const it becomes static. The explanation is actually quite simple. If a field is declared const then its value is the same in all instances of that class. If that is the case a conceptual optimization can take place by simply declaring such a field static. If the value is the same it can be share across all instances. Sounds a bit confusing but it actually makes sense. This is not necessarily obvious at face value. Having worked with C++, Java, and C# over years it just became apparent when working with the type system and reflection in .NET. What I learn from that? There is always a little gem waiting to be discovered! Now here is some food for an additional thought: Can a static field be automatically const? If so, why? If not, why not?

csUnit in 2008

csUnit continues to enjoy good download and visitor numbers on its web site. In particular the interest in (introductory) tutorials remains very strong. Therefore we are assessing what options we have with regards to improving the tutorials that already exist, and whether there are opportunities for additional tutorials. As for csUnit we are looking into options with regards to increasing the functional footprint again this year without increasing the burden on user who don't need some of the new features (yet). The data-driven testing features are likely to move out of the experimental stage. Also, there are a few smaller improvements for supporting generics. And then we certainly want to make sure that csUnit also works with Vista, .NET 3.5 and Visual Studio 2008.

An attempt to attach an auto-named database for file *.mdf failed

And another catch when using SQL Server Express 2005. There are several posts some are helpful some are not. The scenario I am focussing on here is embedding SQL Server Express 2005 into your .NET application. In that case you'd ship the database files (MDF and LDF) with your application and include them in the setup script as well. The usual question when working with ADO.NET is: How does the connection string look like? In my case I tried a few, and then try to use the following very simple C# code:

1: using(SqlConnection conn = new SqlConnection(connectionString)) {
2:   try {
3:      conn.Open();
4:   }
5:   catch(Exception ex) {
6:   }
7:}

I got an exception in line 3 along the lines

"An attempt to attach an auto-named database for file ###.mdf failed ..."

(note that ### is a place holder for the actual filename). I solved it by using information from MSDN, and the working connection string looked as follows:

Data Source = .\SQLEXPRESS; Integrated Security=true; User Instance=true; AttachDBFilename=DataDirectory\###.mdf; Initial Catalog=###;

Again, ### is a replacement for the actual file name. Using this connection string I can now access the database file in a user instance of SQL Server 2005 Express. Some additional comments:

• The user instance is separate from any SQL Server 2005 Express instance that may be running on the system as well. However, unless you haven't changed any permissions or default settings, even a user without administrative rights can run a program and access a user instance.
• Do not attach the database file at the same time with SQL Server Management Studio Express as you can't attach the same database file to twice to two different SQL Server (Express) instances.
• Always make sure you close the database connection. In the above code this is achived with the using statement as regardless how that block of code is left (exception or normal program flow) the Dispose() method will be called. This will always close the connection, and you have avoided a connection leak.
• If you use a connection string in you application, use the same one for all connections to the same database. If you use different connection strings, e.g. change the order of the parameters in them, these will be considered to be different and a connection pool for each will be created. The connection strings must be the same, every single character.

For more info please also see the link attached to this post. If you can't find it, try the heading!

Windows-Safari

OK, I have downloaded and installed Apple's Safari on my Windows XP notebook. Anything earth shattering? I haven't found it yet, but I guess that's because I have used it only for a short time so far. One thing I have observed: For my taste the usability is behind IE7 or Firefox. But again this might be because I'm biased, spoiled, or it might just be a matter of taste. Maybe I simply can't appreciate the "magic" of Safari. Maybe my expectations were simply too high. I'll give it a few more days, and maybe I'll start to get more into it....

Could not open a connection to SQL Server

Using Visual Studio 2005 I tried to connect to a fresh installation of SQL Server 2005 Express. I encountered the following problem:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

I tried all the suggestions such as the ones provided by DataMasker but had no luck. But then I found a hint in a discussion forum on DevX that helped me to resolve the issue. Instead of entering just "localhost" for the Server name I used "localhost\SQLExpress" and all the sudden it worked.

With this blog entry I hope that I can save some people's time. Cheers!

"Generating user instances in SQL Server is disabled. Use sp_configure 'user instances enabled' to generate user instances."

Just in case you ran into the same problem: 1. Open the SQL Server Management Studio Express. This is the downloadable program in the same site where you downloaded the SQL Server 2005 express used to manage SQL Server 2005 Express. 2. In the query editor type this text (everything between the double quotes): "exec sp_configure 'user instances enabled', 1" 3. Execute the query, e.g. by clicking the "Execute" button. 4. Clear the query window, then type (everything between the double quotes): "Reconfigure" 5. Execute the query. 6. Then restart the SQL Server database, e.g. in SQL Server Configuration Manager or by simply restarting the service in the control panel. This solution is based on a forum entry by 'kabalweg' I found at an MSDN SQL Server Forum. And yes, it did work for me. And yes it works for both SQL Server 2005 and SQL Server 2005 Express.

C# Grammar

In case you are looking for a document that contains a C# grammar, then check out the ECMA-334 (PDF, 2.6 MBytes) specification. Starting with page 65 (or 87 of 553 if you use Adobe Reader) you'll find both the lexical and the syntactic grammar for C# 2.0, e.g. including generics, etc.

FormatException thrown by Convert.ChangeType Method

According to Microsoft's online documentation the method Convert.ChangeType(Object, Type) can throw the following two exceptions:

• InvalidCastException
• ArgumentNullException

Unfortunately, this list is not complete. When you try to convert the string "oops" to int32, this method throws a System.FormatException with the message "Input string was not in a correct format."

In this regard the online documentation for .NET 2.0 is incorrect. The behavior might be the same for .NET 3.0. I didn't verify the latter.

What's next for csUnit?

Now, that csUnit 2.1.2 has been released the question is certainly what is next for the tool. Here is my take. I think that one of the next items will be a simple first version of parameterized tests. We have looked at what other xUnit based testing frameworks offer, and there are a lot of very good ideas out there. The way csUnit will support it will certainly be inspired by what is already there. However, we also believe that in some cases the available implementations have shortcomings. Some unit testing frameworks don't offer parameterization at all. Others offer it, but are somewhat limited with regards to where the parameter values can come from. It would not surprise us if you had some thoughts on this as well. Please share them by posting on the "Open Discussion Forum" on SourceForge, or by sending an email to manfred at csunit dot org. Thanks!

csUnit 2.1.2 Released

Finally we have a new version of csUnit. It is version 2.1.2 and it's available at SourceForge. A lot of effort went into this release, and it is probably not an exaggeration to state that this is the best csUnit version ever. Here is what we did:

• Performance: Reduced overhead by approximately 50%
• Usability: Simplified setup, and also the user interface
• Features: Support for multiple categories, and we also added a Timeout parameter to the TestAttribute

It was very exciting to introduce new concepts to the design of the application, e.g. selectors. The code has improved in various ways, and it is amazing to see how more functionality can be provided with a seemingly similar sized codebase.

In particular I would like to thank Jake Anderson, Piers Lawson, and Markus Rentschler for their contributions and support. Also I'd like to thank our sponsors from Agile Utilities and JetBrains. And last but not least I'd like to thank all the users of csUnit who provided us with extremely valuable feedback, and also helped out with experiments to solve bugs. Thank you to all of you! It is a pleaseure to work with you!

Our next release is planned for June 2007. We have quite a few very good suggestions for additional exciting features, and we are looking forward to make them happen!

Codebase vs. Path Name - Different Casing on MS Platforms

While working on some code that loads assemblies I ran into an issue with Assembly.LoadFrom(pathName) in connection with the Assembly.CodeBase property. The method is supposed to load an assembly from the location given in the pathName parameter. When I pass as an example 'foo.dll' as a parameter, it loads the assembly and everything is fine. The interesting part starts, however, when I inspect the CodeBase property after the assembly has successfully loaded: Its value ends in "foo.DLL" (note the upper case file extension). This is certainly not a problem on a Microsoft platform, where file and folder names are case insensitive. If, however, you also intend to run your code on platforms where file names are case sensitive (e.g. Mono on Linux), then this behavior might be of interest to you as on those platforms "foo.DLL" and "foo.dll" are just two different files.

Performance, Overhead, and csUnit

Over the last several months we have been working on improving the performance of csUnit. Not that it was really bad. However, we thought that it is about time to look at whether we can improve it. Generally we improved two areas, one of which is of interest to users, while the second area is more of interest for the csUnit development team. Area one is basically the overhead that csUnit adds to the code that you execute. As a user you would like this to be as low as possible as you would like your resources (computer, but also your time) is mostly spent on what you really want to achieve. For improving the performance we are using JetBrains' dotTrace. It's an easy to use tool, and provided us with just the information we needed to reduce the overhead. For a recipe with about 4 assemblies containing tests you can expect an overhead of about 2 to 3 seconds on a decent notebook. Faster machines lead to better results. Currently we have a few options left, which we consider for future improvements, but right now we believe that we played the major cards. The second area was improving csUnit's own test suite. Again with the help of the profile, but also with csUnit's own "Statistics" tab, we identified the most expensive tests, and worked through them one at a time. We increased the use of mocks, but we also improved the testability of csUnit by introducing more internal interfaces. Overall we are now able to run the test suite with a speed of approx. 6,000 tests per minute on a decent notebook. We are currently shooting for a new version in March. We have a short list of known issues we want to fix. Stay tuned!

Mandatory Use Of Attributes in csUnit (Proposal)

We are considering to drop csUnit's support for finding Tests and TestFixtures based on naming conventions, e.g. fixture names end with Test and tests starting with Test. Instead I'd like to change the specification so that it becomes a requirement to use attributes, e.g. TestFixtureAttribute and TestAttribute, to mark fixtures and tests. The benefit would be a more consistent use of csUnit, e.g. TestAssemblyFixtureAttribute can be expressed with attributes only. The impact would be that all test fixtures and all tests that still rely on naming convention would have to augmented by assigning the TestFixtureAttribute to all fixtures and TestAttribute to all tests. Depending on the number of tests this might a substantial work. Send your feedback and comments to manfred at csunit dot org. Thank you!

What About csUnit 2.1?

Admittedly there wasn't much news around csUnit 2.1 for a while. But be assured that we are working on it, and we are hoping to make a release available in September 2006. Currently we are refactoring the code base, in particular we would like to make the "categories" feature much more powerful. A collateral will be an improved user interface for both the stand-alone application (csUnitRunner) and the Visual Studio 2005 add-in. Stay tuned!