John Howell

After a huge effort to find the right path, the languages team have found a way to make the leap to the next generation of computing environments!  For anyone who wants performance and scalability you simply must checkout Herb Sutter’s talk introducing C++ AMP!  There is also more on the Visual C++’s Team Blob!  This is huge!

When most development leads are pressing for unification of development methodologies, Ivar (one of the three behind UML) makes a good point against that.  This is definitely worth your reading time.

Yes, those wonderful power tools for VS are now updated!  Just released today.  Nothing huge, but lots of little things that make Visual Studio even better and easier to use.  Check it out here!

Happy Coding!

If you’re like me, you were already using the 3.5 builds. They were pretty stable already. Bob Mensching posted on his blog not only about the final 3.5 release but also that they’re release cycles were really accelerating. This is great news. The bad news is that Burn got postponed to 3.6.

Happy Coding!

When a fellow developer came over to talk about sending an email from his tool and I had forgotten this little hat trick.  When you need to pop up an email in the event your software needed to send you some information (such as an unhandled exception), you can use something like this handy little tool.

public static void CreateEmail(string _to, string _subject,
    string _body = “”,
    string _cc = “”,
    string _bcc = “”)
{
    StringBuilder mailTo = new StringBuilder();
    mailTo.Append(“mailTo:”).Append(_to);
    mailTo.Append(“&subject=”).Append(_subject);

    if (!String.IsNullOrEmpty(_body)) mailTo.Append(“&body=”).Append(_body);
    if (!String.IsNullOrEmpty(_cc)) mailTo.Append(“&CC=”).Append(_cc);
    if (!String.IsNullOrEmpty(_bcc)) mailTo.Append(“&BCC=”).Append(_bcc);

    Process.Start(mailTo.ToString());
}

Happy Coding!

Just when I thought I had closed out my blog for the year, I stumbled across a post in the MSBuild forum.  Victor Chen is one of those forum monitors that knows his stuff inside and out.  He happened to post a reply to someone about updating config files and I had forgotten this little gem was available in MSBuild.  You can easily update files with something like this:

<FileUpdate Condition=” ‘$(Configuration)|$(Platform)’ == ‘Foo1|Foo2′”
                Files=”$(Configuration)Web.Config”
                Regex=”Foo=&quot;sth1&quot;”
                ReplacementText=”Foo=&quot;sth2&quot;” />

Keep this in your toolkit.  It could help you out in a pinch.

Happy coding!

I’ve been out of the office since December 16th and I thought I’d post another entry before 2010 ends.  2010 was a brutal year for a lot of people.   However, from a .Net front, it was very exciting.  Conversion to VS2010 was relatively painless, TFS2010 somewhat more painful (can we all say ‘workflows’), but those conversions opened so many doors for us.  .Net 4.0 was like a trove of treasures that were just waiting to be found.  One of my favorites that seem to be overlooked in many blogs is the wonderful Concurrent Collections!  Although a bit older post (October 2010), Wagner did a pretty good rundown example that is worth your read-time.   And Microsoft wasn’t about to sit on their laurels after that!  They’ve even released SP1 for VS2010!  And if even that wasn’t enough, they released the CTP of the Async programming support for C# and VB.Net!  So, if you think 2010 was a bust, crack open the new releases from Microsoft and you’ll think differently!   I hope you and all those around you have a wonderful and safe New Year and I look forward to sharing with you many more tips ‘next year’.  

Happy coding!

While converting a product from VS2008 to VS2010, I stumbled across a disparity between building in the IDE and building from the command line using MSBuild. Here was the scenario: I had a csproj (let’s call it MyLibrary) that had a Target task that generated the CS file that the default Build task consumed. Then I had another project (let’s call this one MyLibraryStub) that contained a reference to MyLibrary.csproj and stubbed it out for test purposes. I had a solution file that contained just these two project. The solution built fine in the IDE and even built fine when I run MSBuild against the solution file. However, I stumbled into this error when I ran MSBuild against MyLibraryStub.csproj:

CSC : fatal error CS0009: Metadata file ‘c:TFSMyLibraryMyLibrary.cs’ could not be opened — ‘File is corrupt.’ [C:MyLibraryStubMyLibraryStub.csproj]

This was initially confusing and posts on the internet were misleading. Looking closer at the output of the MSBuild I spotted something fishy about the parameters being passed to CSC.EXE. It had a reference to my CS file!

c:WindowsMicrosoft.NETFrameworkv4.0.30319Csc.exe /noconfig /nowarn:1701,1702
/nostdlib+ /errorreport:prompt /warn:4 /doc:MyLibraryStub.xml /define:DEBUG;TRACE
/reference:C:TFSMyLibraryobjAny CPUDebugMyLibrary.dll
/reference:C:TFSMyLibraryMyLibrary.cs

. . .

Now I understood the error message: the CS file was being passed in as an assembly and of course, it would have no metadata. My next step was to look at the Target in MyLibrary.csproj that was creating this file. And that’s when I spotted the problem. Here is the build target:

<Target Name=”CreateCSFile” Inputs=”@(MyInputFiles)” Outputs=”$(MyLibraryCSFileOutput)” >
<Exec Command=”$(MyCodeGenExe) /c:$(MyLibraryClassName) /o:$(MyLibraryCSFileOutput) . . . ” />
</Target>

This Target uses the Inputs and Outputs to control when the Target gets built. If the Inputs are older than the Outputs, the Target is skipped. That’s also the problem. Apparently, MSBuild was passing the Outputs of ALL Targets from MyLibrary.csproj to MyLibraryStub.csproj. The IDE does not and MSBuild does not when you build the solution file. This only occurs when you build the MyLibraryStub.csproj.

The solution to this problem was actually very simple. You can control what the ‘output’ of a Target is. In my case, the Target was generating source code so it had no ‘real’ output. I simply added the Return attribute with an empty string like this:

<Target Name=”CreateCSFile” Inputs=”@(MyInputFiles)” Outputs=”$(MyLibraryCSFileOutput)” Returns=”” >
<Exec Command=”$(MyCodeGenExe) /c:$(MyLibraryClassName) /o:$(MyLibraryCSFileOutput) . . . ” />
</Target>

Presto, problem solved. MyLibrary.cs no longer gets passed to CSC in building MyLibraryStub.csproj. I have notified the MSBuild team. In my mind, it should build the same in IDE and in building the CSProj from the command line. We’ll see if they agree. J

Happy Coding!

While working on a VS2008 to VS2010  conversion, I kept running into a problem where MSBUILD would literally blow up. I narrowed it down to the building of a particular MSI using WXS v3.5.  I had a repo!  I knew I could solve this problem but after making multiple changes in the WXS and the WIXPROJ files I was still seeing the issue.  I finally backed up took a different approach.  I had installed the latest Votive so I knew I could build an empty Setup project.  After creating the dummy Setup project and building it successfully in the IDE I went back to the command line and ran via MSBUILD.  I got the error “The specified solution configuration “Debug|X64” is invalid.”.  What?  I new that Debug had to be valid, then if finally hit me.  WXS did not support X64!!!  Are you kidding me?  In our current world of multiple CPU, multiple core, X64 systems, our installer doesn’t support it?  Needless to say, I was disappointed but at least I had my solution: Run the non-X64 command line window.

This just goes to show you that the old adage of “Question everything” strongly applies when investigating issues.  When you start from a false assumption, it will only cost you time and effort.  Lesson RE-learned!

Happy Coding!