Tuesday, June 29, 2010

Build using msbuild instead of devenv

I have lately encountered a lot of build scripts that are using devenv. I have a hard time seeing why, now that msbuild is available (and has been for quite a while). Even if you don't want to use the massive amount of possibilities that msbuild brings with it, just swapping out the build part in the scripts can be worth it.

For example, the common line I tend to see is this:
DevEnv /rebuild Release %Solution%

A quick replace to this:
msbuild %Solution% /p:Configuration=Release /T:Rebuild
Will give a 30% speed increase in my cases.
If the machine is equipped with several CPU cores (most are), the multicore-switch can give an extra boost:
msbuild %Solution% /p:Configuration=Release /T:Rebuild /m:2

Saturday, June 12, 2010

The expression that you have entered is not valid.

A notorious error message in BizTalk is the irritating "The expression that you have entered is not valid.". This message will be shown in a random fashion when using expression shapes in orchestrations. The message will not make sense since the expression entered in fact is perfectly valid and it will seem impossible to make the message with it's red exclamation mark go away.

I have found two solutions to this problem (not permanent though). One is to simply close and reopen Visual Studio. This will not always work. The other is to comment out the line in question in the expression shape, build the project, and then uncomment the line again.

The reason the message can stick to the project is due to the fact that it is written to the orchestration file itself. This is one of few occasions I've seen error messages be saved to a source file as can be seen in the snippet below:

scope longrunning transaction Scope_Trans
    #error "The expression that you have entered is not valid."
    TSFactory.Framework.Logger.Log(System.Diagnostics.TraceEventType.Information, System.String.Format("{0} Orchestration Start", tracePrefix), logCategory);

By commenting out the line and rebuilding, the error message will also be deleted from the source file and then completely disappear.

Microsoft has released a hotfix for this problem, but I cannot find that it fixed the issue for me, especially in the case of calling external assemblies from an expression shape. Neither did it do any measurable difference for my colleagues. The hotfix can however be found here: http://support.microsoft.com/kb/979153.