In past posts I’ve already introduced the FreshMvvm framework for Xamarin.Forms. If you haven’t taken a look I suggest this post to give you an overview of FreshMvvm. I use FreshMvvm in the majority of my projects. I love it’s simplicity but most of all it’s flexibility. The Framework is Interface based and designed to […]

The post Implementing custom navigation in FreshMvvm for Xamarin.Forms appeared first on Michael Ridland.

I’m a long-time MSBuild fan. Now that it’s open source,
I’ve even played with bootstrapping it with xbuild
to use it even on Mac. It works like a charm, for the most part 🙂

I’ve always wished I could just reuse fragments of MSBuild targets that are
generic enough to fit in lots of projects. Things like determining whether
we’re being built with XBuild or MSBuild,
determining the location of Git,
or the particular assembly location for a CodeTaskAssembly
(which isn’t exactly trivial).
Those kinds of things are probably a few lines of XML that could even be
distributed via NuGet.

And so I started doing just that for my own stuff, and thus MSBuilder
was born. It is sort of like NetFx
but for MSBuild rather than .NET code. It may still suffer from that project’s Achilles heel
though, namely, discoverability. But with any luck, the extremely low barrier of entry for
contributors, plus the almost real-time pull-request building and subsequent nuget publishing,
thanks to a paid super-responsive AppVeyor-based
CI system, will make it useful enough to gain traction. Time will tell.

In the meantime, I’ve already added a few very useful MSBuilder blocks already:

Package	Stats
MSBuilder.CodeTaskAssembly
MSBuilder.DownloadFile
MSBuilder.DumpItems
MSBuilder.Git
MSBuilder.Introspect
MSBuilder.IsXBuild
MSBuilder.NuGet.GetLatestVersion
MSBuilder.RegexReplace
MSBuilder.Run
MSBuilder.TaskInliner
MSBuilder.ThisAssembly.Project

MSBuilder.DumpItems

One of my most frequently used ones is surely MSBuilder.DumpItems.
Whenever I’m tweaking MSBuild targets, especially if they are the built-in ones in either
MSBuild/CSharp itself, or WiX, I more often than not want to inspect what various item groups
contain at certain points, as well as potentially useful item metadata I might want to use
for my task at hand.

For example, say you want to do something interesting with project references
that requires you to know precisely what’s going on in the built-in targets after project
and assembly references are resolved. You can just create a console app, install the package

install-package MSBuilder.DumpItems

and edit the .csproj to dump items on AfterBuild for inspection of the items built by one
of the many targets involving ResolveReferences,
such as the _ResolvedProjectReferencePaths which
looks kinda interesting:

<Target Name="AfterBuild">
  <DumpItems Items="@(_ResolvedProjectReferencePaths)" />
</Target>

And you get a full dump of all those items and their metadata, right in the Visual Studio
output window, such as:

2>AfterBuild:
2>  Item: C:DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1binDebugClassLibrary1.dll
2>      AccessedTime=2015-07-19 01:18:52.2170776
2>      BuildReference=true
2>      Configuration=Debug
2>      CreatedTime=2015-07-19 01:16:15.3999053
2>      DefiningProjectDirectory=C:Program Files (x86)MSBuild12.0bin
2>      DefiningProjectExtension=.targets
2>      DefiningProjectFullPath=C:Program Files (x86)MSBuild12.0binMicrosoft.Common.CurrentVersion.targets
2>      DefiningProjectName=Microsoft.Common.CurrentVersion
2>      Directory=DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1binDebug
2>      Extension=.dll
2>      Filename=ClassLibrary1
2>      FullConfiguration=Debug|AnyCPU
2>      FullPath=C:DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1binDebugClassLibrary1.dll
2>      Identity=C:DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1binDebugClassLibrary1.dll
2>      ModifiedTime=2015-07-19 01:18:52.2070760
2>      MSBuildSourceProjectFile=C:DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1ClassLibrary1.csproj
2>      MSBuildSourceTargetName=GetTargetPath
2>      Name=ClassLibrary1
2>      OriginalItemSpec=..ClassLibrary1ClassLibrary1.csproj
2>      OriginalProjectReferenceItemSpec=..ClassLibrary1ClassLibrary1.csproj
2>      OutputItemType=
2>      Platform=AnyCPU
2>      Project={e9288a56-aa1b-4127-97c5-7b3a6d487d63}
2>      RecursiveDir=
2>      ReferenceOutputAssembly=true
2>      ReferenceSourceTarget=ProjectReference
2>      RelativeDir=C:DeleteConsoleApplication13srcConsoleApplication1ClassLibrary1binDebug
2>      RootDir=C:
2>      SetConfiguration=Configuration=Debug
2>      SetPlatform=Platform=AnyCPU
2>      Targets=
2>
2>Build succeeded.

As I come across more useful bits of MSBuild that
are generic enough that deserve becoming MSBuilder blocks, I’ll surely publish them, so stay tunned.

Enjoy!

I’ve been doing quite a bit of WiX work lately. One thing that is very
convenient in WiX is the ability to reference metadata about project
references directly from your WiX files (i.e. fragments or includes). You
could, for example, include a file from a project reference easily with:

<File Id="MyFile" Source="$(var.MyReference.TargetDir)MyFile.dll" />

WiX has a task that automatically fetches metadata about project references
and turns them into those vars you can use, which are then passed to the
rest of the WiX compile process (candle, light, what-not). The resulting
command-line for those tools end up looking something like:

candle.exe ... 
    -dMyReference.Configuration=Debug
    -d"MyReference.FullConfiguration=Debug|x86" 
    -dMyReference.Platform=x86 
    -dMyReference.ProjectExt=.csproj 
    -dMyReference.ProjectFileName=MyReference.csproj 
    -dMyReference.ProjectName=MyReference 
    -dMyReference.TargetDir=[FULL_PATH_HERE]MyReferencebinDebug 
    -dMyReference.TargetExt=.dll 
    -dMyReference.TargetFileName=MyReference.dll
    -dMyReference.TargetName=MyReference
    ...

If you’re doing some pre-processing of the project reference, including
some of its output as compile contents or what-not, it would be very
useful to access those values from MSBuild. This is one of those cases
where you wish WiX’s MSBuild integration went a bit further, but fortunately
it’s all just plain MSBuild in the end so we can do whatever we want to
make it better. In this case, the target that adds those project reference
vars is called AddCompilerDefineConstants and has a convenient
AddCompilerDefineConstantsDependsOn property which we can extend as follows:

<PropertyGroup>
  <AddCompilerDefineConstantsDependsOn>
    $(AddCompilerDefineConstantsDependsOn);
    AddProjectReferenceMetadata
  </AddCompilerDefineConstantsDependsOn>
</PropertyGroup>

And the new AddProjectReferenceMetadata will create an item (“group” of
just one item) named MyReference that I can then use as:

<ItemGroup>
    <Compile Include="%(MyReference.TargetDir)*.wxs" />
</ItemGroup>

That would bring in all the .wxs files that are in the output directory
of the referenced project, for example.

Here’s the AddProjectReferenceMetadata target:

<Target Name="AddProjectReferenceMetadata">
  <!-- Fist invoke the built-in task, but retrieve the outputs as items
         rather than a single property, which is what the built-in targets do -->
  <CreateProjectReferenceDefineConstants
    ProjectReferencePaths="@(_ResolvedProjectReferencePaths)"
    ProjectConfigurations="$(VSProjectConfigurations)">
    <Output TaskParameter="DefineConstants" ItemName="_ProjectReferenceConstants" />
  </CreateProjectReferenceDefineConstants>

  <ItemGroup>
    <!-- Via a cascading item metadata process, we determine the index of the first '.' in the project constants 
         retrieved by the task, since we want to use that as the grouping 'ReferenceName' item name instead. -->
    <_ProjectReferenceConstants>
      <!-- Note how we create a new string with static method syntax, to be able to use property function syntax with item metadata -->
      <ReferenceName>$([System.String]::new('%(Identity)').Substring(0, $([System.String]::new('%(Identity)').IndexOf('.'))))</ReferenceName>
      <ReferenceStart>$([System.String]::new('%(Identity)').IndexOf('.'))</ReferenceStart>
    </_ProjectReferenceConstants>
    <_ProjectReferenceConstants>
      <!-- The we actually need to add 1 to the index of the dot for the substring. 
           For better readability, we do it in two steps, saving the value above, and then calling the built-in Add function here, which 
           updates the metadata value. -->
      <ReferenceStart>$([MSBuild]::Add(%(ReferenceStart), 1))</ReferenceStart>
    </_ProjectReferenceConstants>

    <!-- Here we change the item name on purpose, to drop all the items that have the
         reference name prefix intentionally. Note that since we're creating a new item
         group, we need to reference the original ones by their full item.metadata name. -->
    <ProjectReferenceMetadata Include="@(_ProjectReferenceConstants -> '$([System.String]::new('%(_ProjectReferenceConstants.Identity)').Substring(%(_ProjectReferenceConstants.ReferenceStart)))')">
      <ReferenceName>%(_ProjectReferenceConstants.ReferenceName)</ReferenceName>
    </ProjectReferenceMetadata>
  </ItemGroup>

  <!-- Finally, create a new item group with the name of the reference, which leverages task batching and automatically 
       groups the ProjectReferenceMetadata group by their reference name -->
  <CreateItem Include="%(ProjectReferenceMetadata.ReferenceName)" AdditionalMetadata="@(ProjectReferenceMetadata)">
    <Output TaskParameter="Include" ItemName="%(ProjectReferenceMetadata.ReferenceName)"/>
  </CreateItem>
</Target>