Monday, 15 April 2013

How to: Use NuGet in Source Control with Nuget Package Manager Restore

When enjoying the convenience NuGet brings us, it is easy to forget the fact that the references will come back to bite you the hardest, specially when working with version control. 

This time, I hit a jackpot checkout my project from TFS in a new device, and realise all my dependencies all gong like they never existed, only leaving the NuGet config file proving I wasn't day dreaming before.

Therefore, I would highly recommend the following practices for the people who'd like to keep their project clean and tidy: no unnecessary package or exes checked in, but still be able to use the dependencies when the project is checked out.

1. Enabling package restore during build in Visual Studio options
Enable Package Restore in Options

2. Enabling package restore in solution
Enable Package Restore in Solution

And this is what you get
Files Generated by Enabling Package Restore

But it is not the end of the story, simply because you don't want to break the rules to check in any .dll or .exe. And this will end up with a loose end as next time you check out, you still find something missing, which is the NuGet.exe file. Therefore, to complete the operation, follow the next step.

3. Force NuGet.exe to download

Open up 'NuGet.targets', find 'DownloadNuGetExe', and set the value to true.

<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>

4. Configure proxy to allow download

If you are working within an enterprise network, the auto-download of 'nuget.exe' might not work. In which case, you will have to configure a proxy for it.

Open up 'NuGet.targets', find task 'DownloadNuGet', and configure the snippet with your proxy and credentials.

<Code Type="Fragment" Language="cs">
    <![CDATA[
    try {
        WebProxy proxy = new WebProxy(<proxy address>, <port>);
        proxy.Credentials = new NetworkCredential(<user name>, <password>, <domain>);
        OutputFilename = Path.GetFullPath(OutputFilename);

        Log.LogMessage("Downloading latest version of NuGet.exe...");
        WebClient webClient = new WebClient();
        webClient.Proxy = proxy;
        webClient.DownloadFile("https://nuget.org/nuget.exe", OutputFilename);

        return true;
    }
    catch (Exception ex) {
        Log.LogErrorFromException(ex);
        return false;
    }
]]>
</Code>

* Some useful tips

To keep things neat and tidy, you can now delete the 'packages' folder, because that is the whole point of doing this, right? To remove the redundant dependency files, which saves not just space but also time checking out or cloning depends on what version control mechanism you use, instead allowing build event to retrieve them back automatically.

You can now check in the changes to TFS, and you will find your TFS build server and your check out are working again!

References:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
http://stackoverflow.com/questions/12022154/prevent-needing-to-add-nuget-exe-to-source-control

.NET Framework 4 vs 4 Client Profile


When working in an enterprise environment, utilising any software or package must be justified with logical reasons, feasible operational process and most importantly practical cost. Since the place I work for is only struggled to upgrade all PCs to Windows 7, and it is all to do with  the discontinuation of XP, you can image it is a bit hard to simply roll out latest .NET 4.5 without any objections from IS and IT teams.

For this reason, and also luckily we have got XP SP 3 at least, a proven version of .NET 4 is more acceptable. Yet like its predecessor 3.5, the framework has two versions, one more conventional, and another called Client Profile. So what are the differences between them two and how to decide when to use any of them?

According to Microsoft:

"The .NET Framework 4 and earlier versions provided two deployment options: the full .NET Framework and the Client Profile, which was a subset of the .NET Framework that was optimized for client applications. The Client Profile enabled faster deployment and smaller app installation packages."

As obvious as it seems by their names. 

So how does .NET 4 proof to work better under its targeting environment than .NET 4 (aka. .NET 4 Extended)?

1. Smaller in size

* The full one version is 48.1MB (32bit + 64bit)
* The Client Profile version is 41MB (32bit + 64bit)

2. Less server features to install (here is a list of features you miss in Client Profile)

* ASP.NET (not needed for desktop scenarios)
* Advanced WCF functionality
* .NET Framework Data Provider for Oracle
* MSBuild for compiling

3. Less points of failure while deploying, just by installing less

4. Less attack surface and further servicing events

That's why it is not so bad to be small sometimes, and Microsoft does provide more than what you need most of time.

For those who prefer VS 2010, here is a list of project templates targeting .NET 4 Client Profile by default.

Windows
  • WPF Application
  • WPF Browser Application
  • WPF Custom Control Library
  • WPF User Control Library
  • Windows Forms Application
  • Windows Forms Control Library
  • Console Application
  • Empty Project
  • Window Service
Office
  • All Office 2007 and Office 2010 project templates
WCF
  • WCF Service Library
Workflow
  • Activity Designer Library
  • Activity Library
  • Workflow Console Application
Visual F#
  • F# Application
  • F# Tutorial

For those who would like to move on and use VS 2012, unfortunately you don't get the headache of making sure your .NET framework is synchronised across the solution.

Because starting from .NET 4.5, the Client Profile has been discontinued! Instead, one the smaller in size, faster in deployment and units both framework versions .NET framework 4.5 is available. So it says by Microsoft, and we shall see in time.

References: