This is a test from creating a post using Word 2007. Thanks to dasBloggingWithWord2007.aspx">Colin Neller for the detailed information for making Word 2007 work with dasBlog. Here is an image

Sayed Ibrahim Hashimi

Recently I ran into an error when creating a simple Silverlight, Silverfish as I like to call it. The error was in occurring in the constructor of the Silverlight control that I created. Specifically it occurred when the content was read from the resource with the following statement

this.InitializeFromXaml(new System.IO.StreamReader(s).ReadToEnd());

Once this was executed an Exception was thrown with the following message

Error HRESULT E_FAIL has been returned from a call to a COM component.

And the dialog shown below was displayed

I Googled this error for a bit and it seemed like there were various errors that could cause this. So I started playing with the XAML that it was attempting to load. I discovered that the issue was caused by an Element with the same Name attribute as a previously declared one. So if you get this error make sure that all your Elements have unique names attached to them.

Sayed Ibrahim Hashimi

A while ago I ran the Disk Cleanup utility on my personal notebook. Today I needed to start the SQL server on this machine so I attempt to start the service and I get this error in the Event Viewer

So I made sure that the drive wasn't compressed, and it wasn't then I looked at the file itself and it was. I'm guessing that the Disk Cleanup deal performed this, because I know that I wouldn't. To solve this you right-click on the file and make sure that the checkbox shown is not checked.

Once you make sure this is done, you should be able to start the service again.

Sayed Ibrahim Hashimi

Previously I blogged about an MSBuild Presentation that I was going to conduct at the JaxDug. I'm pleased to say that the presentation went well. I prepared a Powerpoint, but I decided to not use that and to discuss the various elements by example. I think that ended up being a lot more effective, and interesting than the Powerpoint would have been. You can find all the files for download below. The zip file contains all the files. The ppt is the Office 2003 version.

MSBuild_Sayed_I_Hashimi_012008.zip

MSBuild_Sayed_I_Hashimi_01-2008.pdf
MSBuild_Sayed_I_Hashimi_01-2008.ppt.zip
MSBuild_Sayed_I_Hashimi_01-2008.pptx.zip

Sayed Ibrahim Hashimi

On Wednesday January 9 I will be giving a presentation on MSBuild at the Jacksonville Developers User Group. You can read about the presentation at http://cs.jaxdug.com/blogs/events/archive/2007/11/20/1964.aspx. If you are in the Jacksonville Florida region and are interested in this presentation please drop by. MSBuild is a tough topic to present on because it is not well known and a little confusing. My goal is to create a presentation that is interesting enough to keep people awake yet give people some knowledge that they can use. Also I aim to create some samples that can be useful for demonstration to go with it. If you have suggestions please drop me a note.

Sayed Ibrahim Hashimi

MSBuild: How to get all generated outputs

Earlier today a reader of my book emailed me the following question

I am trying to get a list of all the files being generated when MSBuild build a  certain project (they should be all the files in .bin directory).

When I used the TargetOutputs in MSBuild task it gives me the main output only, which is the .exe or .dll. But any other files like dependency assemblies will not be listed in the TargetOutputs collection.

Any advice??

So it sounds like he is looking for a generic way of determining all the files that have been created (moved) during the build process. I’m assuming that he has a few projects and is using a build script to run the process, and then he wants to move the files to another location. If you have a few projects, then obviously the easiest way is to manually examine the output paths of each project and copy the file as necessary. This is not an ideal scenario, because if you add a project to your process you have to make sure to remember to perform the copy manually. Anywayz, this type of behavior would be useful in many different scenarios. Now let’s talk about how to achieve this.

I took another look at the Microsoft.Common.targets file and determined that there is not a straight forward method of performing this action. So, after thinking about this for a little while I think I have come up with a solution. It’s a little confusing, but actually quite simple.

The solution lies in what I’m calling “MSBuild Inheritance”, which I’ve blogged about previously in the entries at:

·        MSBuild Property & Item Overide Problems

·        MSBuild: Find Many Project References

This is where you take an existing MSBuild file and without modifying it you add behavior and or data to it. Now let’s see how this idea can be used to add the desired behavior described above. For this sample I have created a sample Windows Forms app, as well as an external build script, buildWrapper.proj. This build file is shown below.

<Project DefaultTargets="GetOutputs" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>

    <ProjectFile>$(MSBuildProjectDirectory)\WindowsApplication1.csproj</ProjectFile>

  </PropertyGroup>

  <Target Name="GetOutputs">

    <MSBuild Projects="$(MSBuildProjectFullPath)"

             Properties="ImportProjectFile=true" Targets="Build">

      <Output ItemName="ProjectOutputs" TaskParameter="TargetOutputs"/>

    </MSBuild>

    <Message Text="%0a%0dProjectOutputs:%0a%0d    @(ProjectOutputs,'%0a%0d    ')" />

  </Target>

  <!--

    These elements will only be processed when in the context of the

    above Target. This is because of the Condition constraint on these items

  -->

  <Import Project="$(ProjectFile)" Condition="'$(ImportProjectFile)'=='true'"/>

  <!--

    Here we need to override the Build target with our own that will

    generate the correct results.

    -->

  <Target Name="Build"

        Condition="'$(ImportProjectFile)'=='true'"

        DependsOnTargets="$(BuildDependsOn)"

        Outputs="@(AllOutputs->'%(FullPath)')">

    <CreateItem Include="$(OutputPath)\**\*">

      <Output ItemName="AllOutputs" TaskParameter="Include"/>

    </CreateItem>

    <Message Text="Custom build invoked!" Importance="high"/>

  </Target>

</Project>

What this does is twofold:

1.      Defines the GetOutputs target which will drive the process

2.      Extends the behavior of the normal build to create the proper outputs

If you take a look at the Microsoft.Common.targets you will see that the default definition of the Build target is defined as follows:

    <Target

        Name="Build"

        Condition=" '$(_InvalidConfigurationWarning)' != 'true' "

        DependsOnTargets="$(BuildDependsOn)"

        Outputs="$(TargetPath)"/>

The purpose of this target is to define what targets it depends on and to create the outputs, by itself it doesn’t actually perform any action. Because of this we can override it in our buildWrapper.proj file. So the bottom half of the buildWrapper.proj file will conditionally import the project file and then conditionally re-define the Build target. Inside the new Build target we simply examine the output directory and create an item that contains all files that lie underneath it. In the image below you will see the result of this, specifically take a look at the region highlighted in red.

Now we can see that we have successfully achieved our goals.

Every time I describe this process I feel like it is still un-clear. If you have questions please let me know.

Sayed Ibrahim Hashimi

You can download all the files at http://www.sedodream.com/content/binary/OutExample.zip

(Edit: Updated MSBuild task usage to include Targets="Build")

The MSBuild team is trying to prioritize their duties for the next release of MSBuild. Because of this they have asked for feedback on how their customers (us) would enhance MSBuild. They are doing this by distributing a virtual $100 across a possible 11 items. Their list actually ends in an item numbered 12, but there is no number 10. Here is a brief overview of their list of options.

1. Higher Preformance
2. VC Support
3. Support for other project types
4. Convert VS solution file to MSBuild format
5. Better dependency tracking
6. Distributed Build
7. Inline Tasks – ie you write a script right in your MSBuild file instead of a compilied .NET task
8. Scoping for items/properties – ie items/properties can exist in a defined scope
9. Extensible functions – ie being able to add items like the Exists function
11. MSBuild debugger
12. MSBuild visualization 

Here is how I chose to distribute my $100. 

4   - $40
6   - $10
7   - $10
11 - $30
12 - $10

About #4: In my experience, you have 2 scenarios that are the correct way to create build scripts for products. Those are

1.      Create a custom MSBuild file that acts like a solution file

2.      Use a solution file to drive the build process

The only reason to go with 1 is because the solution file is not an actual MSBuild file, otherwise that wouldn’t even be an option. As for option 2, this is not ideal either because it is difficult to inject steps into how the solution build process works. All you can do is really extend what happens before/after the process.

As for the debugger, this is a tool that I have actually wanted to write myself for a long time, but never had the time. If there was a debugger for MSBuild, I think that more people would begin to adopt MSBuild as well as get a much better understanding of how it works.

It’s not often that teams from Microsoft ask for straight customer feature feedback, if you’re interested in future versions of MSBuild then you should definetly participate in this at: http://blogs.msdn.com/msbuild/archive/2007/11/17/how-would-you-spend-100-on-msbuild.aspx. 

Sayed Ibrahim Hashimi

I’ve created a new release of MSBuild tasks, at www.codeplex.com/sedodream. This release includes 4 .NET 3.5 tasks built on Visual Studio B2. Those are all Linq MSBuild tasks. They are:

The first three tasks simply wrap the SqlMetal command line utility. The last, CreateDatabse, will create a database from a Linq DataContext that is contained in an assembly. Right now there is little validation of the parameters passed, but I plan on adding additional validation. Also I will add more meaningful error messages, when invalid parameters are passed through.

Below you’ll find an example of the CreateLinqCode task.

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="3.5" DefaultTargets="Create" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Import Project="$(MSBuildExtensionsPath)\Sedodream\Sedodream35.tasks"/>

  <Target Name="Create">

    <!-- sqlmetal /pluralize

              /conn:"data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

              /timeout:15

              /language:C#

              /context:IbrTestDataContext

              /code:ibrtest.cs

              /views

              /functions

              /sprocs

              /serialization:Unidirectional

              /namespace:Sedodream.Linq.Test

              -->

    <CreateLinqCode

      CodeFileName="ibrahimTest.cs"

      ConnectionString="data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

      Timeout="15"

      Language="C#"

      ContextClassName="IbrTestDataContext"

      IncludeViews="true"

      IncludeSprocs="true"

      IncludeFunctions="true"

      TargetNamespace="Sedodream.Linq.Test"

      >

    </CreateLinqCode>

</Target>

</Project>

Here is the CreateLinqDbml task usage.

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="3.5" DefaultTargets="Create" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Import Project="$(MSBuildExtensionsPath)\Sedodream\Sedodream35.tasks"/>

  <Target Name="Create">

<!-- sqlmetal /pluralize

              /conn:"data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

              /timeout:15

              /language:C#

              /context:IbrTestDataContext

              /dbml:../LinqObjects\ibrtest.dbml

              /views

              /functions

              /sprocs

              /serialization:Unidirectional

              /namespace:Sedodream.Linq.Test

              -->

    <CreateLinqDbml

      DbmlFileName="ibrahimTest.dbml"

      OutDir="."

      ConnectionString="data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

      Timeout="15"

      Language="C#"

      ContextClassName="IbrTestDataContext"

      IncludeViews="true"

      IncludeSprocs="true"

      IncludeFunctions="true"

      TargetNamespace="Sedodream.Linq.Test"

      >

    </CreateLinqDbml>

  </Target> 

</Project>

Please let me know if you have any questions/comments about these items.

Sayed Ibrahim Hashimi

Lately I've been thinking of writing a book strictly on MSBuild. My previous book Deploying .NET Applications has devoted about half of the book to the topic. But I feel that there is still a lot of material missing even from that text. When the book was published I thought that by this time there would be such a book, but there is not. Because of this need, I'm considering writing the book myself! Now I'd like to hear from you, do you think such a book would be useful? What content would you like to see covered in a book like this? You can either contact me through this website of by email at sayed [DOT] hashim [AT] NOSPAMgmail [DOT]com. All feedback is greatly appreciated.

Sayed Ibrahim Hashimi

Ok, I know there are many MSBuild loggers available so why create a new one? Because for a while I’ve been thinking that it would be cool to have a logger that would transform an MSBuild log into a log4net log. This is because obviously log4net has many appenders and tools that you can use out of the box. For example if you wanted to put your logs into a database, then attach the AdoNetAppender. Because of this, and because I couldn’t already find one, I wrote one. You can find it on my Sedodream MSBuild project. This logger is called SedoLogger. I figured this would be a good name, in the case that later on I wanted to abstract out the specific logging mechanism behind it. I have just created a new release that contains all the necessary files. I have posted some usage information about this logger on the SedoLogger WiKi page. I’ll be posting some more details about this logger here in the near future.

Sayed Ibrahim Hashimi