Tuesday, December 09, 2014

Introduction

In this article we will see how we can create NuGet Package after each build and push the package to NuGet in Visual Studio 2013.

Description

NuGet: NuGet is a Visual Studio extension that makes it easy to pull in libraries, components, and most importantly their configuration into your visual studio project. This is a tool that is installed with MVC 3 and it is used to bring in various components to make developing on MVC easier. These components are called NuGet Packages and they can include .NET assemblies, JavaScript files, HTML/Razor files, CSS files, images, and even files that can add configuration to your projects web.config. The goal of NuGet is to make is super easy to bring in or update a component in your existing projects.

what’s new?

Third version of this blockbuster guidance has been split into separate topics as summarized below, allowing you to pick the “world” (guide) you are interested in. This release delivers a new crisper, more compact style, which is easier to consume on multiple devices without sacrificing any content. The content is updated and aligns with the latest Visual Studio technologies and incorporates feedback from the readers of the previous guidance.

...

Branching Strategies Practical guidance on a number of (not all) common Branching Strategies and usage thereof.

Branching concepts

Branching strategies

Walkthroughs

Team Foundation Version Control (TFVC) Practical guidance on how to use Team Foundation Version Control (TFVC) features.

What is OneGet?

OneGet a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a given package type.

...

As part of this Preview, OneGet is shipping with a prototype plugin compatible with Chocolatey, the so called ChocolateyProvider. This is a prototype implementation of a Chocolatey-compatible package manager that can install existing Chocolatey packages. This is a clear confirmation for the hard work done by the Chocolatey folks, and both systems will continue to evolve together, as Rob Reynolds explains in this post. If you want to follow-up on OneGet, then check out its GitHub repository and follow PSOneGet on Twitter.

Something about a forest and trees...

NuGet, MyGet, Chocolatey, OneGet... what?! People ask questions and occasionally can't see the forest for the trees. Here's a quick recap:

NuGet: a solution-level package management tool, used to manage software dependencies within the scope of a solution. It is accompanied by the NuGet Gallery, the home of many if not all .NET open source components.

Chocolatey: a system-level package management tool, used to manage software installations on a Windows system. It (currently) leverages PowerShell and NuGet, supports the Web Platform Installer (WebPI), MSI, RubyGems and many more, and is accompanied by the Chocolatey Gallery where you can find many popular software packages. Rob describes Chocolatey as somewhat like "apt-get", but with Windows in mind.

MyGet: a hosted NuGet package server where you can create and secure your own feeds. In essence, MyGet is able to host vanilla NuGet feeds, as well as Chocolatey feeds.

OneGet supports multiple package sources, and as stated earlier, OneGet comes with a ChocolateyProvider. As MyGet also supports Chocolatey feeds, this effectively means that you can register a MyGet feed as a Chocolatey package source in OneGet! The below diagram is an attempt to illustrate how they relate:

...

How can I use a private OneGet package source?

...

This flow allows you to control what packages get distributed through OneGet, avoids the need to publish your internal software to the general public, and still allows you to leverage the great new scenarios that OneGet offers!

As usual, happy packaging! :)

I've still not played with OneGet yet... But I'm going to. Really. Any time now... um... yeah

Thursday, April 17, 2014

You may have seen that we released the the Windows Management Framework V5 Preview and that one of the new features is Windows PowerShell OneGet. OneGet is designed to dramatically simplify how you discover and install software packages.

Windows PowerShell OneGet

OneGet is a new way to discover and install software packages from around the web. With OneGet, you can:

· Manage a list of software repositories in which packages can be searched, acquired, and installed

· Search and filter your repositories to find the packages you need

· Seamlessly install and uninstall packages from one or more repositories with a single PowerShell command

This first version of OneGet installs and searches software from Chocolatey repositories. Support of additional repositories will come in subsequent versions.

...

One of the things that comes getting up in discussions about using Chocolatey Packages with or without OneGet is the question how can I trust the Packages from a resource like Chocolatey? The Chocolatey Nuget Packages are build by the community so you need to be careful what you are downloading and installing like all other software from sources you don’t own yourself.

But what if there is a easy way to view the content of NuGet Package before installing the Chocolatey NuGet packages? And that is possible using the NuGet Package Explorer.

Friday, March 28, 2014

They may not be sexy, but package managers are an integral part of every developer's work -- using the right ones can make you more productive. Read on to find out what -- and where -- they are.

...

For the app developer or system admin, however, the process of getting utilities, libraries and frameworks installed, along with any required dependencies -- particularly when dealing with the huge ecosystem of open source software -- represents a bigger problem. And this is where package management comes to the rescue.

Package managers help you download, install, configure and update software "packages" from repositories. A package contains the software itself (possibly as source), plus metadata specifying the locations of any dependencies that need to be installed and instructions for automatic compilation, when necessary.

... Here are some great package- and dependency-management tools created specifically for Windows-based development.

...

NuGetNuGet is probably the best-known package and dependency manager for, in Redmond's words, "the Microsoft development platform including .NET." As with the other tools I've mentioned here, NuGet helps you find, install, update and remove packages. However, similar to CocoaPods, NuGet focuses primarily on package and dependency management at the development-project level.

...

Open Wrap OpenWrap is another popular open source package-management sytem for .NET programmers. Created by Sebastien Lambla, OpenWrap is command-line only and supports both OpenWrap and NuGet packages. OpenWrap also includes ReSharper integration, so ReSharper knows about the packages you've installed and doesn't throw up spurious warnings.

...

NPanday NPanday is an Apache Incubator project "to integrate Apache Maven into .NET development environments." Maven is more of a build-automation and dependency-management tool, and also developed more specifically for Java-based development, but developers have figured out how to Maven build for .NET applications.

...

Chocolatey NuGet So, those are the big, established players in package management on Windows. But they're not the only options. Chocolatey is a general-purpose "tools enabler" and "silent application installer" for Windows, modeled after apt-get.

...

Chewie Chewie is yet another NuGet offshoot that attempts to incorporate some features of the Ruby Bundler gem manager into the package\-management workflow on Windows.

...

Ninite OK, Ninite isn't really a package manager in any typical sense of the word, and unlike the rest of the apps I've discussed, it's neither open source itself nor open source focused. But it is a handy utility and it does fall into the same general category as apt-get and Chocolatey.

...

..."

You mean there's more than NuGet? No, say it's not so! Kidding aside, this is a great article of tools you might not of heard of before. Make sure you click through to read the details.

The Extensible Storage Engine (ESE/ESENT), also known as JET Blue, is an Indexed Sequential Access Method (ISAM)data storage technology. Its purpose is to allow applications to store and retrieve data via indexed and sequential access.

ESE provides transacted data update and retrieval. A crash recovery mechanism is provided so that data consistency is maintained even in the event of a system crash. Transactions in ESE are highly concurrent making ESE suitable for server and client applications. ESE caches data intelligently to ensure high performance access to data. In addition, ESE is lightweight making it suitable for auxiliary applications.

The ESE Runtime (ESENT.DLL) has shipped in every Windows release since Windows NT 3.5, with native x64 version of the ESE runtime shipping with x64 versions as well (including IA64), and ARM. ESE is available on Windows, all flavors (server and client) and SKUs....

ESENT is an embeddable, transactional database engine that allows you to create custom applications that need reliable, high-performance, low-overhead storage of data. The ESENT engine can help with data needs that range from something as simple as a hash table that is too large to store in memory, to something more complex, such as an application with tables, columns, and indexes. To create an application with ESENT, you use the esent.dll DLL that is part of the Windows operating system and write your code with C/C++. For more information about ESENT, see Extensible Storage Engine Reference.

ManagedESENT is built on top of esent.dll, which is part of Windows, so there are no extra unmanaged binaries to download and install. With the ManagedESENT library, you can create your application by using a managed language such as C# instead of C/C++. ...

Monday, August 19, 2013

Twelve weeks ago, Microsoft’s Azure Applications Platform & Tools team welcomed three 2nd-year college students, Jaspreet Bagga, Jeremiah Jekich, and Melissa McNeill, and gave them an opportunity to contribute to NuGet.

Package Discovery

Discovering NuGet packages can be a daunting process. The best way to do so is either via word of mouth or online search. However, your friends aren’t always available when you’re looking for a new package at 3:00 in the morning. You could try to search online, but you’d need to spend unnecessary amounts of time sifting through the results before finding a package that may be helpful. We recognize that this time is better spent actually developing software. We wanted to create an accessible service to deliver package recommendations using real world data about how developers use packages.

NuGet Concierge

Thus was born NuGet Concierge, a package recommendation service that recommends packages to developers based on the packages currently being used in their project. We envisioned developers being able to upload their project’s packages.config file to the NuGet Concierge website, which would then present them with a list of packages they may find useful. Something along the lines of “Most projects that use Package A also use Package B.”

So, at the beginning of the summer, we put out a call to the community via Twitter, asking for developers to upload their projects’ packages.config files to help seed our newly conceived recommendation service. We asked, and you delivered! Armed with a collection of over 350 packages.config files, the NuGet Concierge project was brought to life.

Implementation

The first step was to translate the collected .config files into a structure that would allow us to analyze the relationships between packages. How often are individual packages used? But, more importantly, how are packages used together?

So, we took the community’s .config files and parsed them, using them to construct a graph. In doing so, we tracked the number of times a package was used, a value we referred to as the package’s “popularity.” We also tracked how many times two packages were used together, which we referred to as the packages’ “pairing frequency.”

Determining Relationships

Let’s say we have two packages, EntityFramework and jQuery...

...

NuGet Concierge’s Potential

NuGet Concierge is just a conceptual prototype at the moment. But if the concept proves to be valuable, we imagine NuGet Concierge as a fully integrated part of NuGet, having a presence in the Gallery, Visual Studio’s Manage NuGet Packages dialog, and the Package Manager Console. The greatest part of NuGet Concierge is the data powering it. The ability to reference real data about how packages are actively used together opens up a world of opportunities that can potentially help NuGet better serve developers.

Friday, July 26, 2013

When it comes to installing the Nokia Imaging SDK to your Windows Phone 8 projects, the easiest way is to use NuGet. Until today, you still had to complete the installation by manually editing your project file (.csproj), but thanks to the fantastic input of PetroQ, an active member of the SDK discussion board, the installation is now significantly simpler. Kudos PetroQ!

The steps to install the Nokia Imaging SDK are now:

In Visual Studio, from the NuGet Package manager, install the Nokia Imaging SDK to your project.

Remove the “All CPU” configuration from the project, to leave only “ARM” and “X86″.

Wednesday, July 24, 2013

Over the past few months, a great deal of attention has been paid to the following clause used in most of the licenses associated with the NuGet packages that we and other teams at Microsoft ship.

“ a. Distribution Restrictions. You may not … distribute Distributable Code to run on a platform other than the Windows platform;”

In the case of the ASP.NET-related projects, including project Katana, this license (and the associated restriction) does not apply to the source code, but rather to the compiled binaries that are distributed via NuGet (the Katana source code is released under the Apache 2.0 license). This means that even today, it is perfectly reasonable to build the source code yourself and run it on Mono on whatever platform you choose.

As Microsoft teams continue to take more and more components out of the traditional box products and deliver them as NuGet packages, the frustration over this restriction has grown proportionally. ...

So we changed the license.

With the release of Katana 2.0, which will accompany Visual Studio 2013, the Windows-only restriction will be removed from the Katana binary license. It’s important to note here that at this point, the exception applies only to the Katana packages.

While it may appear to be a small step, we’re very excited as we believe it to be a significant one in the right direction!

As I said in my last post, this isn't the Microsoft we grew up with, is it? Nice to see the team respond to this concern and to take steps, no matter how small, to make it "right."

Friday, April 26, 2013

The NuGet package manager is a great way for developers to install and update third-party tools. It solves a lot of the problems of dependency management and integration. Is it ready for the exacting requirements of development in the enterprise?

...

NuGet as That Tool

A World Without NuGet

NuGet… to the rescue?

Dependency Management Overview

Brief History of NuGet

The Enterprise Development Challenge

Enterprise Annoyances with NuGet

Getting around Nuget annoyances

Private NuGet Repository

Preparing Packages for the Enterprise

Alternative Client Tools

Taking NuGet to the Enterprise

Beyond Dependency Management

Several tools – both open source and commercial – have repurposed NuGet components for uses other than dependency management. While these components will obviously share NuGet’s annoyances, the same techniques can be applied to mitigate these annoyances in the enterprise.

One such tool is Chocolatey. It’s described as “somewhat like apt-get, but built with Windows in mind,” and allows users to install programs like Notepad++, Git, and 7Zip with a single command at the Command Prompt. The Chocolatey client accomplishes this by downloading the corresponding .nupkg file from chocolatey.org and executing the install.ps1 contained within.

Obviously, most of NuGet’s dependency management annoyances aren’t applicable with Chocolatey, but Package Verification, Arbitrary PowerShell Script Execution, and Unexpected Licensing are equally – if not more – problematic. But they can all be mitigated with a private NuGet repository and careful package preparation.

Another tool that uses NuGet components is Red Gate’s Deployment Manager. Essentially, it retrieves application components (which have been packaged as NuGet packages) from a private NuGet repository and deploys those components to various servers. But in this case, since the packages come from known sources (i.e. built by the organization), used outside of the context of development, and are already housed in a private repository, none of NuGet’s annoyances have transferred.

All new tools brought in the enterprise need to be carefully adopted, but as these examples show, just because a tool uses NuGet components doesn’t mean that it inherits NuGet’s annoyances. And even if it does (as is the case with Chocolatey), it’s just as easy to mitigate.

At work we had a discussion about just this yesterday, about leveraging NuGet with a private repository, primarily for sharing in-house bin's. But also to re-purpose NuGet too as a "service" repository. I hadn't thought to use a private repository for storing of third-party stuff we've licensed. In hindsight that seems to make a good deal of sense... Interesting...

Friday, April 19, 2013

The Essential Binary Repository Management Cheat Sheet

Software development produces both source code and binary artifacts, and both kinds of artifact need to be handled differently. This Refcard assumes basic familiarity with source repository management, and is intended to help you design and configure a binary repository, optimize it for various workflows, and fit it smoothly into your software development lifecycle.

Software development produces two distinct kinds of artifacts: (1) source code, and (2) binary artifacts. This Refcard assumes basic familiarity with source repository management, and is intended to help you design and configure a binary repository, optimize it for various workflows, and fit it smoothly into your software development lifecycle.

I liked the broad, cross platform nature of this refcard. While for .Net Dev's, Nuget is pretty much the real go to for this, what I thought interesting was that two of the three products mentioned at the end provide Nuget support i.e. Nuget is as much an api as Nuget.org is a repository. Remember, you don't have to use Nuget.org if you don't want too. Nuget makes it very very easy to use other repositories...

Changes

Our pre-release versions were already in an excellent shape so we didn’t have to change much. In fact, there are no surface area changes and no behavioral changes. We updated a few strings to align with some branding changes (in case you didn’t notice: “Metro style apps” are now called “Windows Store apps”).

However, we added one feature we believe is worth discussing in more detail: we now provide a symbol package for MEF.

What are symbol packages?

If you read our .NET 4.5 release announcement carefully, you noticed that we also updated the reference source that allows you to debug the source code of the .NET Framework. Scott Guthrie discussed this in detail here. For out-of-band releases we thought it doesn’t make much sense to publish our source as part of the .NET Framework reference sources drop because one of the goals of releasing out-of-band is being able to publish more frequently than the .NET Framework itself.

Instead, we decided to take advantage of NuGet’s symbol packages. In a nutshell, symbol packages allow Visual Studio to find .pdbs and sources for a given binary.

So let’s have a look at how debugging MEF with the NuGet symbol package would look like.

...

..."

It's great to see these released via NuGet . VS2012 is THE NuGet release and will finally bring NuGet use into the LOB mainstream.

Thursday, August 02, 2012

"Over the past few weeks, we’ve been investigating whether to turn on the content delivery network (CDN) feature of the Azure blob storage container for NuGet packages. In theory, this would make package downloads faster – especially if you’re located outside of the United States.

We want your help to conduct an experiment to measure the difference in downloading packages with CDN enabled verses disabled. Our initial experiment deployed nuget.exe into different regions and measured the time to download a set of NuGet packages. Unfortunately, in all of the regions we deployed to, we were still sitting on an Internet backbone connection, so even our baseline measurements (with CDN disabled) showed a statistically insignificant difference between a deployment in northern Europe and a deployment in the USA. As such, it would seem that enabling CDN wouldn’t yield any measurable benefit.

We think that the reason for the inconclusive baseline is due to the fact that there’s no “last mile” involved in the measurements, and this is where the majority of the slowdown happens. While we could try and simulate last mile time, we would rather change the experiment a bit and ask for your help.

We’ve created a custom of NuGet.exe along with a batch file runner that you can download here. Just unpack the zip file and run NuGet-CDN.bat. This will download the top 25 NuGet packages from both the standard package URL and a CDN URL and then log the time it takes to perform the download operations. You will then be asked to optionally provide your location, which will help us get a better sense of the global impact of using the CDN.

...

The batch process will wrap the log files along with your location information into a new NuGet package. Please email that package to nugetgallery@outercurve.org."

This is a quick and simple process, to cloud-source some Nuget testing on if a CDN would help get your nuget packages faster or not.

Do you Nuget? Are you outside of the US (or not, I'm not, but the wider their set cases the better)? Want to help them see if a CDN would make your Nuget'ing faster? This is your chance to help. It's quick, easy and when done, you just need to email them the generated 9K "NuGetTraces.1.0.nupkg".

I know, you're thinking a CDN HAS to be faster right? Well sometimes these things are really counter intuitive and I think it's cool that they are putting some hard data behind their CDN decision.

A little over a week ago, we asked for your help with an experiment that we were conducting to see whether there was value in enabling CDN support for our packages blob storage container. Over 100 of you responded from all over the world, and the data that you provided made it pretty clear that there was sufficient justification for turning on CDN support for the production NuGet blob storage container. So firstly, thank you to everyone who participated in the experiment!

In addition to turning on CDN, we wanted to share the results of the data that you provided us. First, the worldwide numbers look like the following:

Wednesday, June 20, 2012

"If you are building components that are licensed using the .NET Licensing Model, you might have been looking for a way to take benefit from NuGet as a distribution mechanism.

If you are unfamiliar with the .NET Licensing Model, I recommend this excellent article providing you with a good introduction and sample code.

No matter what licensing model you use, an application that consumes a licensed component needs to use a mysterious licenses.licx file and set it as an embedded resource. In addition, the license key or .lic file for the licensed component being consumed must be present.

This makes packaging a .NET licensed component slightly different from packaging a simple assembly.

...

Securing the package?

Ok, so you have a package which is worth something. It contains a licensed fully working version of your component (using this very basic licensing mechanism at least). How do I distribute it? Putting it on NuGet.org is a no-go, as everyone can simply consume it without paying the license fee.

Here's an alternative: create a private NuGet feed on MyGet. Simply give access to those people who paid for it, and secure it for others.

Again, I used a very basic licensing mechanism only to demonstrate how you can embed a file-based license into your NuGet package and pointed out you can secure your feed with granular access instead of worrying about your package. It's up to you to ensure your licensing mechanism doesn't support distributing the licensed package elsewhere! (this proof-of-concept doesn't mitigate this at all, so be warned!)

The code as well as the NuGet package are attached to this blog:

..."

Think using NuGet means you have to give it away? Well if you're using NuGet.Org it does, but remember you don't have to use that feed. You can add other feeds, such as a private feed. So imagine giving your customers the power of NuGet while still being able to provide a commercial, licensed library? That's what caught my eye in this post (that and you just don't see this kind of usage mentioned anywhere...)

Tuesday, June 19, 2012

We’re happy to announce that we released NuGet 2.0 on 6/19/2012. This release includes support for grouping dependencies, tools and content by the target framework of the project. Additionally, we’ve dramatically improved the performance of tab completion in the package management console.

Package restore consent is now active

As described in an earlier post on package restore consent, NuGet 2.0 will now require that consent be given to enable package restore to go online to download packages. Please ensure that you have provided consent via either the package manager configuration dialog or the EnableNuGetPackageRestore environment variable.

More details on NuGet 2.0 can be found on the release notes. Finally, NuGet 2.0 fixed several bugs. For a full list of work items fixed in NuGet 2.0, please view the NuGet Issue Tracker for this release.

Note: If Visual Studio won't allow you to uninstall the extension (the Uninstall button is disabled), then you likely need to restart Visual Studio using "Run as Administrator."

Group dependencies by target frameworks

Starting with version 2.0, package dependencies can vary based on the framework profile of the target project.

...

Grouping content files and PowerShell scripts by target framework

In addition to assembly references, content files and PowerShell scripts can also be grouped by target framework.

Improved tab completion performance

The tab completion feature in the NuGet Package Manager Console has been updated to significantly improve performance. There will be much less delay from the time the tab key is pressed until the suggestion dropdown appears.

Bug Fixes

NuGet 2.0 includes many bug fixes with an emphasis on package restore consent and performance

Note: If Visual Studio won't allow you to uninstall the extension (the Uninstall button is disabled), then you likely need to restart Visual Studio using "Run as Administrator."

Features

Support opening readme.txt file after installation

Show prerelease packages in the Manage NuGet packages dialog

Show Package Restore button when package files are missing

Add solution-level packages.config file

In previous versions of NuGet, each project has a packages.config file which keeps track of what NuGet packages are installed in that project. However, there was no similar file at the solution level to keep track of solution-level packages. As a result, there was no way to restore solution-level packages. This feature is now implemented in NuGet 1.7. The solution-level packages.config file is placed under the .nuget folder under solution root and will store only solution-level packages.

Remove New-Package command

Due to low usage, the New-Package command has been removed. Developers are recommended to use nuget.exe or the handy NuGet Package Explorer to create packages.

Bug Fixes

NuGet 1.7 has fixed many bugs around the Package Restore workflow and Network/Source Control scenarios. ...

I ran into the Known Issues above myself. If you're having problems updating (like the uninstall is disabled, errors, etc), check out those notes and suggestions.

I think my favorite item in this release is the Solution Level feature...