Matt Ward : MSBuild

Targeting Different Frameworks with VB.NET

MattWard — Sat, 18 Feb 2006 17:09:00 GMT

SharpDevelop 2.1, revision 1157, allows VB.NET projects to target the older Microsoft Frameworks and Mono. This extends Daniel's previous work to target different frameworks with C#. SharpDevelop 2.1 is only available from the repository.

To target a different framework, open the project's "Compiling" options (Project | Project Options | Compiling) and select the desired framework from the "Target Framework" drop down list.

MonoBASIC

When Mono is targeted, the MonoBASIC compiler (mbas) will be used. This compiler is still under going a lot development, so there are a few things that are missing or have incomplete support. One omission, for example, is that it will not embed resources into an assembly.

SharpDevelop now contains Gtk# project and file templates for VB.NET. There is no Glade# project template for VB.NET since MonoBASIC does not currently support embedded resources.

Issues

There are a few things to be aware of when using SharpDevelop to target the older frameworks.

Code completion for certain core assemblies will only show .NET 2.0 information. These core assemblies are:

mscorlib
System
System.Data
System.Design
System.DirectoryServices
System.Drawing
System.Web.Services
System.Windows.Forms
System.Xml
Microsoft.Build.Engine
Microsoft.Build.Framework

The Forms Designer will generate .NET 2.0 code only.

The Forms Designer will generate .NET 2.0 specific resources.

Alternative Solutions

Robert McLaws produced an MSBuild toolkit for Visual Studio 2005 RC, but this does not look like it supports the latest version of Visual Studio.

Jomo Fisher produced a targets file, for C# projects, that can be used to target the older Microsoft frameworks. This targets file is a sample that supports Visual Studio beta 2.

Microsoft recently released an MSBuild toolkit for .NET 1.1 called MSBee. This adds support for targeting .NET 1.1 with VB.NET as well as C# projects. It will also generate .NET 1.x resources from .NET 2.0 resx files.

[Update 30 August 2006]

From version 1.1.17 Mono no longer ships with the MonoBASIC compiler. When the new VB compiler for Mono is released SharpDevelop 2.1 will be updated to support it.

MSBuild and Mono's GAC

MattWard — Wed, 11 Jan 2006 21:13:00 GMT

SharpDevelop2 now supports Mono's GAC, so this post takes a low level look into how it uses MSBuild to do this.

Our starting point is a previous Custom MSBuild Targets for Mono post, which introduced an MSBuild task (Mcs), which was used to compile the code using Mono's Mcs compiler, and an MSBuild targets file (Mono.Mcs.targets). We will be using the ICSharpCode.Build.Tasks assembly that ships with SharpDevelop2 which contains the custom MSBuild tasks. We will not be using the SharpDevelop2's target files since these target more than just the Mono framework.

Mono GAC References

The original custom MSBuild task and targets file did not support Mono GAC references. In fact they were the bare minimum required to compile code using Mcs. The only MSBuild target that was overridden was the CoreCompile target, which was changed to use the Mcs task instead of Microsoft's Csc task. Without support for Mono's GAC any assembly references needed to have a HintPath

<Reference Include="gtk-sharp">
<HintPath>..\..\Program Files\Mono\lib\mono\gtk-sharp\gtk-sharp.dll</HintPath>
</Reference>

In order to add support for Mono's GAC we will need to look at the following Microsoft targets and properties:

AssemblySearchPaths
GetFrameworkPaths
ResolveAssemblyReferences

First let us see if we can get a simple GAC reference to System.Xml to work. With the old tasks and targets a reference of the form

<Reference Include="System.Xml"/>

is resolved to "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll".

To fix this we need to override the GetFrameworkPaths target and set the TargetFrameworkDirectory property correctly. This can be done by adding the following to the Mono.Mcs.targets file

<Target Name="GetFrameworkPaths">
    
    <GetMonoFrameworkPath TargetFrameworkVersion="Mono v1.1">
        <Output TaskParameter="Path" PropertyName="TargetFrameworkDirectory"/>
        <Output TaskParameter="Path" ItemName="_TargetFrameworkDirectoryItem"/>
    </GetMonoFrameworkPath>

    
    <GetMonoFrameworkSDKPath>
        <Output TaskParameter="Path" PropertyName="TargetFrameworkSDKDirectory"/>
        <Output TaskParameter="Path" ItemName="_TargetFrameworkSDKDirectoryItem"/>
    </GetMonoFrameworkSDKPath>
</Target>

This override must come after the

<Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />

statement, so this should be moved to the beginning of the Mono.Mcs.targets file. It also uses two custom tasks that need to be made known to MSBuild

<UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkPath"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
<UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkSdkPath"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

The GetFrameworkPaths target sets a few more things than just the TargetFrameworkDirectory, this is done for completeness based on what the Microsoft.Common.targets file does, but only the TargetFrameworkDirectory property needs to be set. The TargetFrameworkDirectory is set by calling the GetMonoFrameworkPath task and passing in the target framework version, which in this case is "Mono v1.1". This task uses the registry to locate the Mono framework directory (e.g. "C:\Program Files\Mono\lib\mono\1.0").

AssemblySearchPaths and ResolveAssemblyReference

Now what about an assembly that only exists in Mono's GAC and cannot be found in Mono framework's directory? A reference to glib-sharp is a good place to start.

<Reference Include="glib-sharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f"/>

We need to modify the AssemblySearchPaths which is being passed to the ResolveAssemblyReference task. In the Microsoft's target files this is defined as:

<PropertyGroup>
    
    <AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == '' ">
        {CandidateAssemblyFiles};
        $(ReferencePath);
        {HintPathFromItem};
        {TargetFrameworkDirectory};
        {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
        {AssemblyFolders};
        {GAC};
        {RawFileName};
        $(OutputPath)
    </AssemblySearchPaths>
</PropertyGroup>

The {Registry} part is Microsoft specific and can be removed for Mono. The {GAC} part is also Microsoft specific. When the ResolveAssemblyReference task encounters this string it knows to look in Microsoft's GAC. We will replace this with {MonoGAC} which Microsoft's ResolveAssemblyReference task knows nothing about.

<PropertyGroup>
    <AssemblySearchPaths>
        {CandidateAssemblyFiles};
        $(ReferencePath);
        {HintPathFromItem};
        {TargetFrameworkDirectory};
        {AssemblyFolders};
        {MonoGAC};
        {RawFileName};
        $(OutputPath)
    </AssemblySearchPaths>
</PropertyGroup>

Now we need to somehow replace the {MonoGAC} with a set of directories. We could write our own ResolveAssemblyReference task, but this seems like a lot of work. Instead let us update the AssemblySearchPaths just before the ResolveAssemblyReference task is called. We do this by overriding the ResolveAssemblyReferenceDependsOn target and making it call our custom AddMonoAssemblySearchPaths target.

<PropertyGroup>
    <ResolveAssemblyReferencesDependsOn>
        GetFrameworkPaths;
        GetRedistLists;
        PrepareForBuild;
        AddMonoAssemblySearchPaths
    </ResolveAssemblyReferencesDependsOn>
</PropertyGroup>
<Target Name="AddMonoAssemblySearchPaths">
    <AddMonoAssemblySearchPaths
        Assemblies="@(Reference)"
        Paths="$(AssemblySearchPaths)">
        <Output TaskParameter="Paths" PropertyName="AssemblySearchPaths"/>
    </AddMonoAssemblySearchPaths>
</Target>

Again this custom task needs to be included via

<UsingTask TaskName="ICSharpCode.Build.Tasks.AddMonoAssemblySearchPaths"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

The AddMonoAssemblySearchPath task looks for the {MonoGAC} item in the AssemblySearchPaths property and replaces it with any Mono GAC directories that need to be searched. The GAC directories are determined by looking at the assembly references passed in via the Assemblies property. If multiple GAC references are located then multiple directories are inserted into the AssemblySearchPaths property.

Now we can use MSBuild to build a project with references to assemblies in Mono's GAC using SharpDevelop2's ICSharpCode.Build.Tasks assembly and the Mono.Mcs.targets file.

Mono.Mcs.targets

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

    <Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />

    <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkPath"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkSdkPath"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.AddMonoAssemblySearchPaths"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

   <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);Mono.Mcs.targets</MSBuildAllProjects>
        <DefaultLanguageSourceExtension>.cs</DefaultLanguageSourceExtension>
        <Language>C#</Language>
    </PropertyGroup>

    <Target Name="CreateManifestResourceNames"/>

    <PropertyGroup>
        <DebugSymbols Condition=" '$(DebugType)' == 'none' ">false</DebugSymbols>
        <DebugType    Condition=" '$(DebugType)' == 'none' "></DebugType>
    </PropertyGroup>

    <ItemGroup>
        <DocFileItem Include="$(DocumentationFile)" Condition="'$(DocumentationFile)'!=''">
            <InProject>false</InProject>
        </DocFileItem>
    </ItemGroup>

    <PropertyGroup>
        <CoreCompileDependsOn>_ComputeNonExistentFileProperty</CoreCompileDependsOn>
    </PropertyGroup>

   
   <PropertyGroup>
        <AssemblySearchPaths>
            {CandidateAssemblyFiles};
            $(ReferencePath);
            {HintPathFromItem};
            {TargetFrameworkDirectory};
            {AssemblyFolders};
            {MonoGAC};
            {RawFileName};
            $(OutputPath)
        </AssemblySearchPaths>
    </PropertyGroup>

    
    <PropertyGroup>
        <ResolveAssemblyReferencesDependsOn>
            GetFrameworkPaths;
            GetRedistLists;
            PrepareForBuild;
            AddMonoAssemblySearchPaths
        </ResolveAssemblyReferencesDependsOn>
    </PropertyGroup>
    <Target Name="AddMonoAssemblySearchPaths">
        <AddMonoAssemblySearchPaths
            Assemblies="@(Reference)"
            Paths="$(AssemblySearchPaths)">

            <Output TaskParameter="Paths" PropertyName="AssemblySearchPaths"/>
        </AddMonoAssemblySearchPaths>
    </Target>

    <Target    Name="GetFrameworkPaths">
        
        <GetMonoFrameworkPath TargetFrameworkVersion="Mono v1.1">
            <Output TaskParameter="Path" PropertyName="TargetFrameworkDirectory"/>
            <Output TaskParameter="Path" ItemName="_TargetFrameworkDirectoryItem"/>
        </GetMonoFrameworkPath>

        
        <GetMonoFrameworkSDKPath>
            <Output TaskParameter="Path" PropertyName="TargetFrameworkSDKDirectory"/>
            <Output TaskParameter="Path" ItemName="_TargetFrameworkSDKDirectoryItem"/>
        </GetMonoFrameworkSDKPath>
    </Target>

    <Target
        Name="CoreCompile"
        Inputs="$(MSBuildAllProjects);
                @(Compile);
                @(ManifestResourceWithNoCulture);
                $(ApplicationIcon);
                $(AssemblyOriginatorKeyFile);
                @(ManifestNonResxWithNoCultureOnDisk);
                @(ReferencePath);
                @(CompiledLicenseFile)"
        Outputs="@(DocFileItem);
                 @(IntermediateAssembly);
                 $(NonExistentFile)"
        DependsOnTargets="$(CoreCompileDependsOn)"
    >

        <Mcs
              AdditionalLibPaths="$(AdditionalLibPaths)"
              AddModules="@(AddModules)"
              AllowUnsafeBlocks="$(AllowUnsafeBlocks)"
              CheckForOverflowUnderflow="$(CheckForOverflowUnderflow)"
              CodePage="$(CodePage)"
              DebugType="$(DebugType)"
              DefineConstants="$(DefineConstants)"
              DelaySign="$(DelaySign)"
              DisabledWarnings="$(NoWarn)"
              DocumentationFile="@(DocFileItem)"
              EmitDebugInformation="$(DebugSymbols)"
              KeyContainer="$(KeyContainerName)"
              KeyFile="$(KeyOriginatorFile)"
              LangVersion="$(LangVersion)"
              MainEntryPoint="$(StartupObject)"
              NoConfig="true"
              NoLogo="$(NoLogo)"
              NoStandardLib="$(NoStdLib)"
              Optimize="$(Optimize)"
              OutputAssembly="@(IntermediateAssembly)"
              References="@(ReferencePath)"
              Resources="@(ManifestResourceWithNoCulture);@(ManifestNonResxWithNoCultureOnDisk);@(CompiledLicenseFile)"
              ResponseFiles="$(CompilerResponseFile)"
              Sources="@(Compile)"
              TargetType="$(OutputType)"
              ToolPath="$(McsToolPath)"
              TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
              WarningLevel="$(WarningLevel)"
              Win32Icon="$(ApplicationIcon)"
              Win32Resource="$(Win32Resource)" />
    </Target>
</Project>

Targeting Different Frameworks with SharpDevelop

MattWard — Sat, 15 Oct 2005 14:55:00 GMT

Daniel recently added support for .NET 1.1 and .NET 1.0 to SharpDevelop 2.0. Let us take a low level look at how SharpDevelop 2.0 targets other frameworks. Targeting another framework involves a custom .targets file and custom MSBuild tasks.

SharpDevelop Custom MSBuild Tasks and Targets

Component	Description
ICSharpCode.Build.Tasks.dll	Assembly containing custom MSBuild tasks.
SharpDevelop.Build.Common.targets	Specifies targets common to all SharpDevelop targets.
SharpDevelop.Build.CSharp.targets	Specifies targets for C# projects that target a framework other than the default.
SharpDevelop.Build.Mono.Mcs.targets	Defines the Mcs task.
SharpDevelop.Build.Mono.Gmcs.targets	Defines the Gmcs task.
SharpDevelop.Build.MSIL.targets	Specifies targets for ILAsm projects.

What happens when another framework is targeted?

When the project has been configured to target a framework other than the default, the project is modified to use a customised .targets file and has a property added that specifies the framework being targeted. Below is a project file for a console application that targets Mono 1.1.

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <RootNamespace>HelloMonoWorld</RootNamespace>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{0534CD74-E5FA-4349-866E-4E0C6428E840}</ProjectGuid>
    <TargetFrameworkVersion>Mono v1.1</TargetFrameworkVersion>
    <NoStdLib>False</NoStdLib>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <OutputPath>bin\Debug\</OutputPath>
    <Optimize>False</Optimize>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>Full</DebugType>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <OutputPath>bin\Release\</OutputPath>
    <Optimize>True</Optimize>
    <DefineConstants>TRACE</DefineConstants>
    <DebugSymbols>False</DebugSymbols>
    <DebugType>None</DebugType>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(SharpDevelopBinPath)\SharpDevelop.Build.CSharp.targets" />
</Project>

The .csproj file has a <TargetFrameworkVersion> element and includes a custom .targets file "SharpDevelop.Build.CSharp.targets" instead of the usual "Microsoft.CSharp.Targets".

The "SharpDevelop.Build.CSharp.targets" file looks at the TargetFrameworkVersion information and targets the appropriate runtime. If we are targeting Mono, the file imports one of the Mono specific target files.

<Import Condition=" '$(TargetFrameworkVersion)' == 'Mono v1.1' "
        Project="$(SharpDevelopBinPath)\SharpDevelop.Build.Mono.Mcs.targets"/>
<Import Condition=" '$(TargetFrameworkVersion)' == 'Mono v2.0' "
        Project="$(SharpDevelopBinPath)\SharpDevelop.Build.Mono.Gmcs.targets"/>

These Mono specific files reference the custom MSBuild tasks in the ICSharpCode.Build.Tasks assembly.

If one of the Microsoft .NET frameworks is targeted, various properties, such as CscToolPath, are changed so the correct compiler is used, but no custom tasks are involved.

Custom MSBuild Tasks for Mono

MattWard — Sat, 15 Oct 2005 14:15:00 GMT

SharpDevelop ships with two custom MSBuild tasks for Mono, one for Mcs and the other for Gmcs, both of which live in the ICSharpCode.Build.Tasks assembly. With the recent Mono release, 1.1.9, the command line options and compiler error message formats are the same for Mcs and Gmcs, earlier versions differed. This means that the Mcs and Gmcs classes do not do much apart from determine the name of the compiler to use. The MonoCompilerTask class does the hard work of compiling the code and reporting error messages back.

Simple C# Console Project

HelloMonoWorld.csproj:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>

Main.cs:

using System;

namespace HelloMonoWorld
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Running MSBuild, passing the .csproj as a command line argument, will build the console app using Microsoft's Csc and targets the .NET Framework 2.0.

Using the Mcs Task Directly

Let us modify the project file so it calls the Mcs task directly. I am assuming that the ICSharpCode.Build.Tasks.dll exists in the same folder as the project file.

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>

  <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
             AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

  <Target Name="Build">
    <Mcs
      OutputAssembly="$(OutputPath)\$(AssemblyName).exe"
      References="@(ReferencePath)"
      Sources="@(Compile)"
      TargetType="$(OutputType)"/>
  </Target>
</Project>

The project file above is a bit limited, it does not have standard targets such as "Rebuild" and "Clean". We could write everything ourselves, but instead why not use the standard .targets that Microsoft provides and just override the bare minimum?

Mono.Mcs.targets

So what is the bare minimum .targets file we need in order to get MSBuild to use our custom Mono tasks?

First let us look at the modified project file:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="Mono.Mcs.targets" />
</Project>

The Mono.Mcs.targets file, which is based on the Microsoft.CSharp.targets file, overrides the CoreCompile target:

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

    <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

   <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);Mono.Mcs.targets</MSBuildAllProjects>
        <DefaultLanguageSourceExtension>.cs</DefaultLanguageSourceExtension>
        <Language>C#</Language>
    </PropertyGroup>

    <Target Name="CreateManifestResourceNames"/>

    <PropertyGroup>
        <DebugSymbols Condition=" '$(DebugType)' == 'none' ">false</DebugSymbols>
        <DebugType    Condition=" '$(DebugType)' == 'none' "></DebugType>
    </PropertyGroup>

    <ItemGroup>
        <DocFileItem Include="$(DocumentationFile)" Condition="'$(DocumentationFile)'!=''">
            <InProject>false</InProject>
        </DocFileItem>
    </ItemGroup>

    <PropertyGroup>
        <CoreCompileDependsOn>_ComputeNonExistentFileProperty</CoreCompileDependsOn>
    </PropertyGroup>

    <Target
        Name="CoreCompile"
        Inputs="$(MSBuildAllProjects);
                @(Compile);
                @(ManifestResourceWithNoCulture);
                $(ApplicationIcon);
                $(AssemblyOriginatorKeyFile);
                @(ManifestNonResxWithNoCultureOnDisk);
                @(ReferencePath);
                @(CompiledLicenseFile)"
        Outputs="@(DocFileItem);
                 @(IntermediateAssembly);
                 $(NonExistentFile)"
        DependsOnTargets="$(CoreCompileDependsOn)"
    >

        <Mcs
              AdditionalLibPaths="$(AdditionalLibPaths)"
              AddModules="@(AddModules)"
              AllowUnsafeBlocks="$(AllowUnsafeBlocks)"
              CheckForOverflowUnderflow="$(CheckForOverflowUnderflow)"
              CodePage="$(CodePage)"
              DebugType="$(DebugType)"
              DefineConstants="$(DefineConstants)"
              DelaySign="$(DelaySign)"
              DisabledWarnings="$(NoWarn)"
              DocumentationFile="@(DocFileItem)"
              EmitDebugInformation="$(DebugSymbols)"
              KeyContainer="$(KeyContainerName)"
              KeyFile="$(KeyOriginatorFile)"
              LangVersion="$(LangVersion)"
              MainEntryPoint="$(StartupObject)"
              NoConfig="true"
              NoLogo="$(NoLogo)"
              NoStandardLib="$(NoStdLib)"
              Optimize="$(Optimize)"
              OutputAssembly="@(IntermediateAssembly)"
              References="@(ReferencePath)"
              Resources="@(ManifestResourceWithNoCulture);@(ManifestNonResxWithNoCultureOnDisk);@(CompiledLicenseFile)"
              ResponseFiles="$(CompilerResponseFile)"
              Sources="@(Compile)"
              TargetType="$(OutputType)"
              ToolPath="$(McsToolPath)"
              TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
              WarningLevel="$(WarningLevel)"
              Win32Icon="$(ApplicationIcon)"
              Win32Resource="$(Win32Resource)" />
    </Target>

    <Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />
</Project>

The differences between this is and the standard Microsoft.CSharp.targets file is that a few properties have been removed (NoWarn and UseHostCompilerIfAvailable) and the CreateManifestResourceNames target has essentially been removed, the target is defined, but it does nothing. This targets file is good enough to compile our console application, as long as we do not add any embedded resources to it.

SharpDevelop

How does this compare with the .targets files that ship with SharpDevelop? Since SharpDevelop can target more than just Mono, it supports the older .NET frameworks too, things are a little more complicated. This will be covered in another post.