Merging WSDL and XSD files   (Tips & Tricks)   
Having played with BizTalk some while ago (version 2006 R2) I had an interesting problem: in certain situations BizTalk would not accept web service description files (WSDL) where the XML schema was stored in separate files (XSD). No matter how hard I tried, there was no success. I even tried the good old trick of putting the files in a webserver and trying to add them over HTTP. It would not work. (This is the way you trick the Visual Studio proxy generator when WSDL and XSD files are spread over the hard drive in different directories, but that is another story :) )

Finally, I ended up creating a tool I called WSDLMerge. This can take a WSDL file, local or remote, and merge it with all the XSD files referenced. The merging is recursive, so any XSD files referenced by other XSD files are also included. It can follow local path locations and remote path locations. The result is a single WSDL file, that contains everything.

If you want to jump right into the code part, you can find the tool in source code format at GoogleCode. You will need Visual Studio 2010 to compile, but you can safely run it with .NET 3.5 SP1 (maybe even earlier).

The rest of this post will talk about how this tools works.

Just XML

WSDL files are just XML files after all. So we can go ahead and load it from disk or from a URL.

XmlDocument wsdl = new XmlDocument ();
wsdl.Load ( filename );

And voila, we have the entire WSDL loaded up. We need to create a XML namespace manager because we are going to work with namespaces. XPath searches in particular required the namespace manager. If you have the source code by now (see link above) you can find the following code in a method named PrepareNamespaceManager().

            XmlNamespaceManager manager = new XmlNamespaceManager ( wsdl.NameTable );
            manager.AddNamespace ( "wsdl", WSDLNamespace );
            manager.AddNamespace ( "xsd", XSDNamespace );
            return manager;

The tools will verify if the file loaded is an actual WSDL file. It does this by checking for the root element, which should be wsdl:definitions. There are probably better ways to do this, but this is good enough for our purposes.

Schemas, where are thee?

Next step, find schemas. These can be found under the following XPath /wsdl:definitions/wsdl:types. We read the import definitions one by one, load the schema location and namespace parts of the imports. We also keep track of all namespaces we have already loaded.

Ok, so first we locate the element where we should find the schema import statements:

XmlNode node = wsdl.SelectSingleNode ( "/wsdl:definitions/wsdl:types", manager );

If such an element exists, we can start finding any schemas:

XmlElement schemaElement = typesElement.SelectSingleNode ( "xsd:schema", manager ) as XmlElement;

Here the process turn recursive. This is done using a method called ProcessSchema() that is designed to process a single schema definition.

Inside this method we need to know if the schema is inline or if the schema is imported. So we look for import elements:
            imports = rootElement.SelectNodes ( "xsd:import", manager );

If we find anything, we check the namespace for this schema as well as the schema location. If the namespace we find is not yet loaded, we load the .XSD file (from either disk or an URL), attach it to the main document, and remove the import statement.

XmlDocument schemaDocument = new XmlDocument ();
schemaDocument.Load ( importLocation );

XmlElement newSchema = wsdl.ImportNode ( schemaDocument.DocumentElement, true ) as XmlElement;

XmlNodeList newImports = newSchema.SelectNodes ( "/xsd:import", manager );
foreach ( XmlNode importNode in newImports )
{
                    if ( level == 0 )
                    {
                        newSchema.RemoveChild ( importNode );
                    }
                    else
                    {
                        if ( importNode.Attributes["schemaLocation"] != null )
                        {
                            importNode.Attributes.RemoveNamedItem ( "schemaLocation" );
                        }
                    }
}
schemas.Add ( importNamespace, newSchema );

The ImportNode() method handles duplicating the element from the schema into our WSDL document. We also remove any import elements from the duplicated element (this could mean removing schemaLocation attributes). We do not want any XSD to import anything.

Of course we also do not want to have any schemas missing. So while we remove schema references from the document we are creating, we will want to follow them in the original documents. After this processing done we will process the original XSD (from which we created the duplicate) for these import statements, and call ourself (ProcessSchema()) recursively to import any further XML namespaces.

When this process is complete, all namespaces (== XSD files) that are referenced in any of the directly referenced schemas or anywhere in there recursively will be included one by one in the body of the WSDL document. This sort of flattens the entire XSD structure (previously using files it was built as a tree like structure). The schema references will still be in place, and because all schemas are now in the body, the WSDL will not have any dependencies.

In the end, the whole process is just navigating and modifying XML documents, looking up references, loading them, and attaching duplicated elements and nodes into the master document. This master document will become our merged WSDL document, which we just write to disk in the end.


I was trying to find a solution to a problem with LINQ and its CreateDatabase() call (see details in another blog post). Then I bumped into the following problem.

When I tried attaching a database into an SQL Server Express User Instance that existed before (the same database under the same path), I received an exception. I actually manually deleted the .MDF and .LDF files from disc, and then tried to recreate them programatically. The exception informed me the database file already existed. Although I have deleted it myself.

The exception said: Database 'path_to_database' already exists. Choose a different database name.. Which was very strange.

Reading more about SQL Server Express User Instances, I found out that they are more complicated than I thought. What actually happens is that SQL Server Express copies the master and msdb databases under the user's directory (who runs the user instance). It then starts the user instance (sqlservr.exe) under the user account. When you want to use a database in a user instance, it actually attaches the database file to the user instance - just as you would attach a database to a regular SQL Server instance. It just happens behind the scenes.

This creates trouble of course, because the database is registered somewhere, and you shouldn't just delete the files. Which I did. And that is why I got the error message. :)

There is some information about a tool that you can use to connect to a user instance and execute commands (detach maybe?). I found it too complicated. (But if you are interested, visit this MSDN page for more information!)

Rather, I killed my user instance process (Task Manager, kill sqlservr.exe). Then proceeded to delete my user instance directory. For Windows 7, this would be:

c:\Users\username\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS\

I then restarted my application (which called CreateDatabase()), and it worked. It recreated the above directory, and everything was fine.

I have to admit that this seems like a bit of a drastic solution, but it sure is faster than connecting to the instance and issuing SQL commands by hand :)

And it should not have any side effects, because all user instance databases will just get attached automatically the next time you use them.

Top 25 Most Dangerous Programming Errors   (Tips & Tricks)   
Many have probably heard about cross-site scripting or SQL injection and other common pitfalls when developing applications. There is a nice list of the top 25 most dangerous errors one can "create" during coding.

The list was compiled by many organizations and companies, and contains not just the errors themselves but also prevention and mitigations guidelines. Interesting read for anyone concerned about the security of their code.

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

Splitting CSV data with Regex   (Tips & Tricks)   
The other day I needed to process CSV data from a .NET program. The basic processing is quite simple, you can just call string.Split() to have the job done. But I was faced with a CSV file that contained items in quotes. And of course inside the quotes, a comma would be allowed, thus rendering string.Split() quite useless.

I asked around and found that people were using a library that can be obtained from CodeProject. You can find the actual project here. It provides quite robust CSV processing capabilities. Unfortunately, I was in a hurry, and did not want to play around with a library (I know: bad me). I needed a regular expression that could split my string.

As it turned out, there were some articles to be found around the internet, but none would offer a perfect solution. I finally stitched together a regex from various sources and Google cache entries.

Regex rex = new Regex(",(?=(?:[^\"]*\"[^\"]*\")*(?![^\"]*\"))");

This would work for my case. It might not be general enough, but if you have CSVs with quotes and need a fast solution, you can just take the above regex and then use it to split:

string[] result = rex.Split(csvLine);


Shortcut keys in Windows 7   (Tips & Tricks)   
Probably everyone knows a few shortcut keys in Windows and various applications. Ctrl-C and Ctrl-V being one of the most popular, I guesss. But there are really a lot of very useful shortcut keys introduced in Windows 7.

I am myself a keyboard freak: I like doing many things from the keyboard. In fact, I try to avoid the mouse as much as possible. Because I code and write, my hands are usually on the keyboard, so moving onto the mouse takes away precious typing time :)

The following applies to Windows 7 only.

Did you know you can maximize (Win+Up) and restore/minimize (Win+Down, although this only restores if the window is maximized) windows easily, or even move a maximized window from one monitor to the other (Win+Shift+Left or Win+Shift+Right, based on the direction you are moving)? I also like the fill left or fill right side shortcuts (Win+Left, Win+Right). Arranging windows was never quite so easy.

It takes a moment of time to learn a few shortcuts, but I find that it speeds up everyday operations so much.

You will find a list of shortcuts here:

New Keyboard shortcut keys (hotkeys) in Windows 7

Or if you really feel like learning, here is a more complete list:

Windows 7 keyboard shorcuts

Update 27.10.2009 - Another page with useful information on shortcuts for Windows 7: The Master Lift of new Windows 7 shortcuts

Debugger breakpoints from code   (Tips & Tricks)   
Did you ever have the need to stop the debugger from code? That is, without adding a breakpoint in the Visual Studio IDE?

Many times this seems to be a problem when a third party application loads my .DLL assembly and starts executing it. I want to place a breakpoint, but before the .DLL is loaded into this third party host, the breakpoint would not be active, and after the component is activated, it might be too late to place the breakpoint in the IDE.

Solution? Use the following code:

System.Diagnostics.Debugger.Break ();

And like magic, the debugger will stop here just as if there was a brakepont added.

If you are running this as a Windows application, the application error popup will also appear, allowing you to attach a debugger to the process. You can then just start stepping right from this code line forward.