Now, the title is a bit cryptic, so let me elaborate; earlier this week, I noticed that when I tried to add a service reference to a WCF Workflow service in the same ASP.NET Web Application, I didn’t get the expected result; custom activities for the service operations in the toolbox (when designing another WF Service).
Investigating further, I created a Workflow Console Application and checked if I got the same behavior; no – it worked perfectly. Same happened when I tried it with WCF Workflow Service Application / Declarative Service Library (Visual Studio templates).
Putting one and one together, I guessed that it had something about the definition of the project template. Visual Studio projects has a concept of ProjectTypeGuids that enables/disables specific features for a project once added. A couple of years ago, I noticed that I had to add a specific GUID in order to wire in the “F5 experience” when debugging WCF libraries.
When comparing the GUIDs set in one of the working projects with the ones in the ASP.NET Web Application, I noticed the following (magic number):
I retrofitted the GUID in the Web Application, added a service reference to a workflow service;
Building the project and presto! — custom activities for the service operations in the toolbox.
Now, this isn’t just a problem that can happen when using Workflow Services, it can also happen (as I’ve already mentioned) to WCF projects, test project et cetera too. My suggestion to Microsoft is that they in the future add an section somewhere in the Options pages where it is possible to turn on/off features like this one, so developers don’t need to turn autistic and start remembering a large set of project type GUIDs :-) (Oh, no offense to devs (or others) that actually are autistic).
Thanks @mwinkle for putting me in touch with the Add Service Reference guys, even though I found the workaround first :-)
Build error: Value cannot be null. Parameter name: path1.
Now that’s a cryptic title, right?
First of all; a big thanks to Jason Barile/MSFT that set me in contact with Aaron Hallberg that in turned found a workaround for the bug I’m about to describe.
Second; The bug is fixed in MSFTs trunk version of TFS 2010, so you don’t need to run over to connect.microsoft.com to report it.
With the release of the Visual Studio 2010 and Team Foundation Server 2010, I thought it would be cool to check out the new TFS Basic mode running locally on one of my laptops.
I was amazed that the whole installation process took only about 20 minutes – something that is way better than the near-nightmare scenario of installing a full TFS 2005 or 2008 (I haven’t tried to setup a full scale TFS 2010 yet).
In addition to the TFS 2010 itself, I also installed the Team Build Controller and Team Build Agent locally on the same laptop (and of course Visual Studio 2010 Ultimate).
I imported a small pet project / demo I’m working on into the source control, and set up a build definition for it so that I could do continuous integration builds when checking in future changes.
Queue new build…
Bang. Build Error :-(
Now, I tried all sorts of things to try to figure out what caused the build failure, and I got some input from Jason Barile, that didn’t work out either (turned out that I’ve set the build server’s working directory to the same directory for it to drop the result to).
Luckily, I twittered my need for someone that could take a look at my problem, and that’s where Jason entered the scene; we did a SharedView session, and as I’ve already written, we didn’t get very far. But Jason works with a brilliant guy named Aaron, that was more than willing to take a look at the problem too.
We did a SharedView where we discussed what I’ve already tried, and tried to narrow down the possible things that could mess up my build. After checking up a bit internally, Aaron came back with a small piece of source code we checked out locally; a bit of code that tries to infer the location of MSBuild.
Well, it turned out that when it parsed a value from the registry (or something) it took my current regional settings into account, and here in Norway we use , (comma) as a decimal separator – something that is different from the US standard; . (period.
The fix for it was to hardcode the path to msbuild in the BuildTemplate.xaml file that is actually the workflow that is used by the build server. Aaron sent me a version that I plugged in – and bam! Green build!
Thanks again Jason & Aaron – I love the openness a great attitude of every MSFT employee I’ve met so far :-)
The modified .xaml file can be downloaded from here.