To be checked in or not!

Potentially SERIOUS bug. -- SQL Server 2008 Management Studio

 

UPDATE: Microsoft’s acknowledged the bug…

We had a scenario (several weeks back) where a co-worker was connecting/changing connection between different sql servers and ended up in a state where the Microsoft SQL Server Management Studio said he was connected to one server however when executing queries it was connected to a different server.

This issue has been in the back of my mind ever since as a “what if this happens when connected to a production database and not my local dev box” issue. (WARNING: SERIOUS DATA CORRUPTION MAY OCCUR, when connected to the wrong server unknowingly)
NOTE: Luckily, we recently gave read-only rights to our dev AD user accounts so this situation couldn’t happen. I know, I know, “why didn’t we have that from the beginning?”……It happens, anyway…

Well, today I had the issue when working between my Dev box and our Test server and it took another developer (Thanks Keith Craig from Vertigo Software) to help me figure out the data I was looking at was not actually the data from the server I thought I was connected to.

Screenshot of the problem:

How to get into that state…

1. Start with a query connected to a remote database.
   NOTE: The two servers in red are the same. (Yay, we’re in a good state)
   
2. Click the “New Query” button to open a new query window.
   
3. Right click in the new empty query window, while it’s loading, and you (might) get the option to Connect. (if you’re fast enough)
   NOTE: This happens if you right click before the window finishes initializing it’s connection to the original server (in this case the remote database server). Usually this dialog gives you the “Change Connection” option when connected, but if you’re fast enough you can get the “Connect” option and the “Change Connection” will be disabled.
    
4. Click “Connect” and choose to the new desired server. In this case I’m going to connect to (local)
   
5. That’s it, I’m now connected to the original server FILES, even though it says I'm connected to the server entered in the dialog above (local).
     

 

Current Work Around to Avoid this Problem:

PATIENCE

To avoid the issue, wait till the query window has time to finish it’s initialization and has connect to the previous server. Then you can Right-Click –> Connection –> Change Connection…

 

Hope this helps someone else… because, like I stated earlier… (WARNING: SERIOUS DATA CORRUPTION MAY OCCUR, when connected to the wrong server unknowingly)

T4 replacement for “Add Service Reference”

My company has been developing out parts of our website using Silverlight to enable some rich client LOB scenarios. Since the companies inception, we developed in a Scrum/Agile manner 3-6 week iterations. However, recently we started experimenting with a more “feature driven” attempt at “lean” approach.

With this new development approach, we made the decision that the trunk of the project’s source will be ready to deploy to production at all times. And as such would develop features out on branches. This is where the problem lies… We started running into a “Maximum file path length…” issue when branching the source. It’s a relatively old project (5 years or so now) with layers of projects/namespaces.

We traced the issue down to files generated by the Visual Studio’s Add Service Reference dialog.

In our case the generated files had the full namespace + service name which were, in some cases, greater than 90 characters long just for the file. Coupled with the fact they were already nested in a directory structure (that helped keep things organized). We ended bumping into the “Maximum file path length…” when trying to branch the project.

After researching a hunch I’d had

Most of those files generated by the tool are garbage and never used, so why does VS generate them, and have to check them into TFS?

Here’s a good post describing the meta data files.
http://www.scottseely.com/blog/09-01-26/Misunderstood_Add_Service_Reference.aspx

I found out that the only thing we cared about was the “References.cs” file in that whole batch of files.

Now, we would like to, and have thought about writing our own code in place of using the VS generated, (I know I’ve heard from the WCF pros at IDesign that you should never use the “Add Service Reference” generated stuff…) however it does what we need with the exception of the super long file names generated and…every time we update the service reference it keeps trying to add the ServiceReferences.ClientConfig back into the project. Since we are not using a config file to store the WCF connection information. We are following a similar path you can read about here (http://geekswithblogs.net/mwatson/archive/2009/02/24/129655.aspx) This way we don’t have to have separate configs for Dev/Test/Production.

The built in VS Service Reference tooling has become more of a hindrance to development than providing any benefit.

What is the solution we came up with to these two issues?

What were the problems again?

1. Files generated by “Add Service Reference” tools are too long for TFS (Not the fault of the tool, more the fault of the (TFS/.net api/win api) for not supporting longer file names…

2. Every time we update/add new service reference it tries to re-add the ServiceReferences.ClientConfig file (DON”T WANT THAT)

After about 1/2 a day looking for alternatives to using the built in tool, and since the wcf svcutil doesn’t generate code Silverlight can use. I stumbled upon this blog Command line WCF Proxy Generation for Silverlight 2 RTM where he figured out how to use the same dll VS uses to generate the source and wrapped it into a little console app… After chatting w/ him on his blog’s Live Messenger plugin, (very cool by the way) he emailed me the exe he’s using in his production app (that had a couple bug fixes since his original blog post. He told me just to use Reflector to get at the source because it was very basic.

And so I did, and ended up with a pretty good solution to the problems above. (Sucks that I spent a day of dev time on this crap, but oh well…)

I wrote a T4 template that will generate all the reference.cs code needed in our Silverlight project. Instead of describing the template itself (since this post has gotten long alredy) I’ll include a project with a sample of how it works.

Some of the features you get using this template are:

1. It solves the two issues stated above
   1. Only one file generated.  (None of the VS generated garbage metadata files)
   2. No re-add of the ServiceReferences.ClientConfig file to the project.
2. With the use of the T4 template (this is in our app, not in the sample below) you can put other logic needed when generating a service reference.
   1. We are using it to update the Web.Config’s WCF aspnet compatibility flag so we can get at the wsdl and setting it back when done updating the service reference…
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true">
3. You can set some properties that will tell the tool to generate the types as “internal” (if you want)

   Note: you have to add the correct InternalsVisibleTo for this to work

   [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("System.Runtime.Serialization")]
   

Here’s the sample project with examples of both a normal reference, and the same reference using the T4 template.

Hope this helps someone else…

Introducing StatLight (Silverlight Testing Automation Tool)

 

What is it?

StatLight is your first class TDD/BDD/(Insert your testing style here) tool for Silverlight. Its main focus is developer productivity.

(The website is young, however the tool is ready to go… Download StatLight here)

In the realm of Silverlight, the tooling support has not had the chance to catch up to what you might have come to expect from normal .net development. When developing Silverlight applications using a test driven style, with the current tooling, it can become a little more tedious than one might like.

A number of testing methodologies have sprung up to enable some sort of testing for Silverlight developers; however, few actually run the tests in the browser.

Below is a short list of features StatLight currently has.

Features:

1. In browser runner to test how your code will “actually” run in the wild.
2. TeamCity Continuous Integration support
3. Smooth Console Runner
   1. One time runner (screenshot below)
      
   2. Continuous Integration runner
      1. This runner will startup and watches for any re-builds of your text xap file. Every time you re-build it will pick up the new test xap and immediately start running the tests.
      2. This feature gives the most as far as developer productivity.
      3. I will put out a video to show how best to use it soon…
4. Tag/Filtering support (to narrow down the tests run at a given time)
5. XUnit support leveraging XUnit (Light)
6. MSTest support. (March 09 build)

On the way:

1. Better Documentation and how to/help videos
2. NUnit support leveraging Jeff Wilcox’s NUnit port
3. CruiseControl.net support
4. MSBuild

Download StatLight here