Xamarin: Xamarin Dev Days Recap and Expansion

When we announced Xamarin Dev Days, free weekend community events filled with intense and hands-on mobile C# learning, we knew that it would be popular – but we didn’t expect every location to sell out so quickly! Each Dev Days event has been packed full of awesome Xamarin content and fun hacking, and the feedback […]

The post Xamarin Dev Days Recap and Expansion appeared first on Xamarin Blog.

Xamarin: Xamarin’s Newest MVPs!

As the Xamarin developer community continues to expand, it consistently provides stand out members that we are excited to include in the Xamarin MVP program. These individuals have made significant contributions by sharing their passion and expertise in mobile app development with Xamarin’s growing global community. We honor these individuals with the Xamarin MVP title […]

The post Xamarin’s Newest MVPs! appeared first on Xamarin Blog.

Michael Ridland: Implementing custom navigation in FreshMvvm for Xamarin.Forms

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.

Daniel Cazzulino: How to accesss project reference metadata from WiX project in MSBuild

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>

Daniel Cazzulino: Bite-sized reusable MSBuild targets, properties and tasks

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 NuGet downloads Version
MSBuilder.DownloadFile NuGet downloads Version
MSBuilder.DumpItems NuGet downloads Version
MSBuilder.Git NuGet downloads Version
MSBuilder.Introspect NuGet downloads Version
MSBuilder.IsXBuild NuGet downloads Version
MSBuilder.NuGet.GetLatestVersion NuGet downloads Version
MSBuilder.RegexReplace NuGet downloads Version
MSBuilder.Run NuGet downloads Version
MSBuilder.TaskInliner NuGet downloads Version
MSBuilder.ThisAssembly.Project NuGet downloads Version

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!

Xamarin: Same Day Xamarin Support for Visual Studio 2015

Today, Microsoft is unveiling the final release of Visual Studio 2015 in a global webcast, and we are joining the celebration! Now Released to Market (RTM) for full use in production, Visual Studio 2015 includes many new features and improvements that make it easier to build apps quickly, including diagnostics, new C# 6 language features, […]

The post Same Day Xamarin Support for Visual Studio 2015 appeared first on Xamarin Blog.

Xamarin: Save the Date for Xamarin Evolve 2016

Mark your calendars for Xamarin Evolve 2016, taking place April 24-28 in Orlando, Florida! Join the Xamarin team and fellow developers for the largest cross-platform mobile development event in the world. Last year, Xamarin Evolve hosted a sell-out crowd of over 1,200 attendees. Speakers from leading companies including Microsoft, Dropbox, Github, Google, Accenture, and IBM […]

The post Save the Date for Xamarin Evolve 2016 appeared first on Xamarin Blog.

Xamarin: Share Even More Code with Plugins for Xamarin

One of my top priorities for Moments, a Snapchat clone built with Xamarin.Forms and Microsoft Azure, was to maximize the amount of code shared between my target platforms. I was already achieving a significant amount of shared code with Xamarin.Forms, but I noticed that many things, such as checking for device connectivity or showing a […]

The post Share Even More Code with Plugins for Xamarin appeared first on Xamarin Blog.