How SharpDevelop uses MyGet and NuGet

This is a guest post by Matt Ward, working on SharpDevelop, an open source Integrated Development Environment (IDE) for .NET applications which supports the development of applications written in C#, Visual Basic.NET, F# and IronPython. It is and written in C#. In this post, Matt shares their story on using MyGet to host and discover add-ins for SharpDevelop.

If you would like to share your story too, let us know! We love to hear good stories!

SharpDevelop NuGet MyGetThe SharpDevelop team recently announced a new Addin Manager for SharpDevelop 5 and an online gallery for addins that is hosted on MyGet.

SharpDevelop has been extensible through addins since it was first created but it has never before had an online gallery. The majority of IDEs have an online gallery that can be used to find and install extensions. WebMatrix is one example that provides extensions through from its own NuGet feed just like SharpDevelop.

Addins for SharpDevelop 5 can now be published as NuGet packages to a MyGet gallery. NuGet gives SharpDevelop all the benefits of versioning and updating addins whilst MyGet provides a central place where SharpDevelop addins can be found and installed from.

SharpDevelop's addin gallery on MyGet is a community gallery which is open to anyone to publish their own addins.

Background

About a year ago there was a discussion on the SharpDevelop mailing list about having an online source of addins for SharpDevelop. Andreas Weizel had started work on a way to obtain addIns from an online source but at the time it was not based on NuGet. Christoph Wille, Project Manager for SharpDevelop, suggested looking at re-using the NuGet gallery for hosting the packages and using NuGet to download and install addins. One idea was to put the addins on the main NuGet.org feed and add a special tag to them to distinguish them however it made more sense for SharpDevelop to have its own gallery. Rather than setting up a server and hosting a NuGet gallery ourselves it was quicker and easier to use MyGet.

Now let us take a look at how you can make your own addins available for SharpDevelop 5. If you have published a NuGet package to the gallery hosted on NuGet.org then the following procedure will be very familiar.

Publishing an Addin with MyGet

Here we will look at the steps taken to publish an addin that provides support for compiling against Mono. The source code for this sample addin is available on GitHub. The first step is to compile the addin. With the Mono addin compiled we need to create a .nuspec file that will be used to generate a NuGet package containing all the files needed for the addin:

    <?xml version="1.0"?>
    <package xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <metadata xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
            <id>Mono</id>
            <version>1.0</version>
            <authors>Matt Ward</authors>
            <owners>SharpDevelop</owners>
            <requireLicenseAcceptance>false</requireLicenseAcceptance>
            <description>Mono support for SharpDevelop</description>
            <iconUrl>http://community.sharpdevelop.net/blogs/mattward/SharpDevelop.png</iconUrl>
            <summary>Mono support for SharpDevelop</summary>
            <releaseNotes></releaseNotes>
            <language>en-US</language>
            <tags>mono</tags>
        </metadata>
        <files>
            <file src="..\..\..\AddIns\Samples\Mono.Addin\**\*.*" target="" />
        </files>
    </package>

In the above .nuspec file we are adding all the addin files, including any subdirectories, by using the double wildcard ** so we do not have to explicitly specify every file. SharpDevelop requires the main addin assembly and its associated .addin configuration file to be in the root of the NuGet package. This is why the target for these files defined in the .nuspec file has been left empty.

Now we can generate the NuGet package by running NuGet.exe from the command line:

nuget pack mono.nuspec

On running this command you will see a "Assembly outside lib folder" warning which can safely be ignored since we are not going to be adding this NuGet package to a .NET project. We have now generated a Mono.1.0.nupkg file which is what we will publish to the MyGet gallery.

To publish to MyGet you will need your MyGet account's personal API key. Your API key can be found under Account Settings in the Security section. Copy your API key and in the following command line replace the Your-API-Key with your key:

Running the above command will publish the Mono addin to MyGet. Now anybody using SharpDevelop 5 can install the Mono addin by selecting AddIn Manager from the Tools menu.

image

You can see the list of available addins by clicking the Available section of the dialog. To install the Mono Addin select it and click the Install button. The addin will be available after SharpDevelop is restarted.

Matt Ward is developer at Pebble Code. In his spare time he works on SharpDevelop, which he has been involved with since 2004, and more recently has been working on a NuGet addin for MonoDevelop and Xamarin Studio.

Blog: community.sharpdevelop.net/blogs/mattward Twitter: @sharpdevelop

Author: Maarten Balliauw on 16 Jul 2013

Automatically mirror packages from other feeds (or: keep working during NuGet outages)

imageMany of our users have created their own NuGet feed on MyGet and are uploading their own packages to that hosted feed. Some of our users have been asking for a good way to make their MyGet feed the only feed in their team, the reason for introducing MyGet package source proxy which can include packages from upstream package sources such as the official NuGet Gallery in search results.

Up until recently, package source proxies were nothing but proxies: the feature simply proxies the packages on demand, which means a number of things:

  • Upstream packages that are deleted are no longer available on your MyGet feed unless explicitly mirrored.
  • When an outage occurs on the upstream package source, the proxy is of no use because it can’t connect to the upstream package source

Today, we are introducing a solution for that: a new option is available to automatically add and mirror downloaded upstream packages to your feed, as requested in these two UserVoice entries.

Enabling this option ensures that you can keep working with just one feed and have all the packages you need available on that feed, even if they originate from another package source and even if that upstream package source happens to have an outage. If you are working with firewall exceptions, enabling this option will also ensure that only one firewall exception to your MyGet feed has to be made.

If you want more information on how to enable this feature, check out an end-to-end tutorial in our documentation.

Happy packaging!

Author: Maarten Balliauw on 04 Jul 2013

MyGet is running over HTTPS only

A couple of weeks ago we've informed you that from July 1st, 2013, MyGet would be switching to HTTPS traffic only. We have just deployed these changes and from now on, your feed URL should be prefixed with https:// instead of http://.

Haven't made the switch yet? No problem: we will be redirecting most traffic to the new HTTPS endpoint. However this may add a little latency to your requests. Hence it's best to switch your URL now if you haven't done so.

To help in updating feed URLs on developer machines, you can make use of package source discovery. https://docs.myget.org/docs/reference/package-source-discovery
In short, every developer can issue the following commands in his/her Visual Studio Package Manager Console to update feed URLs:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url https://www.myget.org/Discovery/Feed/ -OverwriteExisting</pre>

Protecting the security and privacy of our users is one of our most important tasks at MyGet. The fact that you can safely store your intellectual property on our servers is the best proof of that. We are confident this one-time change will make the entire MyGet experience even more secure.

Do not hesitate to contact us if you have additional questions through the comments below.

Happy packaging!

PS: If you are a MyGet Enterprise customer and are using your own domain name, no action isrequired on your side.

Author: Maarten Balliauw on 02 Jul 2013

Build services: patching AssemblyVersion attribute

It already was possible to work with true incremental build numbers for packages produced using Build Services through the build source settings. A build counter starts with zero and increments with 1 on every build. You can also specify a version format (use '{0}' as a placeholder for the build counter) which will be generated during build.

Build Services recently got an update where the AssemblyVersion attribute can be patched with this version number. This can be enabled by checking the Automatically patch AssemblyInfo option in the build source configuration.

Patching AssemblyVersion during build

When enabled, MyGet Build Services will patch AssemblyVersion attributes in C# and VB.NET code. We are using Roslyn as the engine for parsing and updating attribute values. This approach is much more reliable than the regular expression based approaches most build systems use.

Two attributes will be patched: AssemblyVersion and AssemblyInformationalVersion.

  • The patched AssemblyVersion version is always in the form major.minor.patch. A package version 1.0.0 as well as 1.0.0-pre will yield an AssemblyVersion of 1.0.0.
  • The patched AssemblyInformationalVersion version supports semantic versioning and can be in the form major.minor.patch as well as major.minor.patch-prerelease.

Patching of these attributes will occur whenever the feature is enabled, no matter which build process is used (solution, project or build.bat).

Happy packaging!

Author: Maarten Balliauw on 19 Jun 2013

Switching to full HTTPS on July 1st, 2013

Important: a change is coming to URLs of MyGet. Please read through this post carefully as there may be some actions required on your side.

Protecting the security and privacy of our users is one of our most important tasks at MyGet. The fact that you can safely store your intellectual property on our servers is the best proof of that.

Currently, MyGet supports both http as well as https to communicate with our applications. To further improve our security, we're removing http access in the near future and will be switching to https only by July 1st, 2013, using a 2048-bit key certificate. By using only https, we can guarantee a secure communication channel between you and our servers.

Unfortunately, this change may require some action on your side. We will be discontinuing the http://www.myget.org URL in favor of https://www.myget.org. This means:

  • Your developers and/or clients may have to update their configuration
  • Your continuous integration servers may have to be reconfigured to make use of this new URL

This transition will happen in the following stages:

Actions required on your end:

  • Before July 1st - All links to MyGet have to be migrated to the https://www.myget.org URL if you are not on the Enterprise plan.

To help in updating feed URLs on developer machines, you can make use of package source discovery. https://docs.myget.org/docs/reference/package-source-discovery
In short, every developer can issue the following commands in his/her Visual Studio Package Manager Console to update feed URLs:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url https://www.myget.org/Discovery/Feed/


We are confident this one-time change will make the entire MyGet experience even more secure.

Do not hesitate to contact us if you have additional questions.

Best regards,
the MyGet team

Author: Maarten Balliauw on 18 Jun 2013

A Glimpse into our toolbox

Every now and then, we like to give you some insight in our development and the tools we use. This time, let’s have a look at Glimpse. Glimpse gathers and presents detailed diagnostic information about the behavior and execution of your web application. It’s like Firebug, but for the server.

Glimpse can be installed by installing the Glimpse.Mvc4 package. Different packages exist for different frameworks. Once installed, we can navigate to the /glimpse.axd file to enable/disable Glimpse on our development machine. The links on this page are also bookmarklets which can be used to turn on/off Glimpse. Once enabled, here’s what we see: a nice overview of important timings for our current page.

Glimpse toolbar

We are using Glimpse on our development machines to get some simple diagnostics at a glance. And the fun fact of the day: Glimpse uses MyGet to publish nightlies. Interested in what’s going on with that project? Add their nightlies feed to Visual Studio through the Package Manager Console:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url "https://www.myget.org/gallery/glimpsenightly"

 

From then on, you can add Glimpse from their nightlies feed. We’ve used these nightlies in the past weeks and discovered their new HUD (head-up-display) feature in there as well as a new look-and-feel for the Glimpse client.

We can click the Glimpse toolbar and explore our request. For example, we can fetch a list of all actions and attributes that are being executed in ASP.NET MVC:

ASP.NET MVC Pipeline

A complete timeline of our requests is available as well:

Glimpse request timeline

We are also able to intercept and debug AJAX requests. If you are using Entity Framework or ADO.NET, expect to see your queries in here. If you’re developing mobile web applications, expect to be able to intercept remote calls as well. And the best thing: this is open source!

Happy packaging! And happy Glimpsing!

Author: Maarten Balliauw on 11 Jun 2013

Build services: you decide if symbols are pushed or not

By default, when MyGet Build Services creates a build and produces packages, symbols packages (if any) are pushed to SymbolSource.org. In some scenarios, it may make sense to not push symbols packages, for example when creating early versions of a package or during prerelease phases.

Since our latest release, it’s now possible to change this default behavior. When creating or editing a build source, the Push symbols to symbol server option specifies if symbols should be pushed or not.

Configure symbol server behaviour in build services

Happy packaging!

Author: Maarten Balliauw on 29 May 2013

Automatically trigger a MyGet build using an HTTP POST hook

In addition to manually triggering a build within MyGet, it’s also possible to automatically trigger a build every time code is committed to your source control repository, by making use of HTTP POST hooks.

Once you have fully configured a build source for your MyGet feed, you will be able to manually trigger a build whenever you like. However, if you are trying to adopt the Continuous Integration Software Development Practice, then automatically triggering a MyGet Build whenever you commit some code to source control is one of the first steps in doing this.

The HTTP POST hook URL is a mechanism to allow your Source Code Repository to notify MyGet Build Services (via an HTTP POST to the given URL) when a commit has occurred. As soon as this has happened, a new build will automatically be triggered.

MyGet user gep13 has written a detailed tutorial on working with Build Services and HTTP POST hooks on our documentation website.

Happy packaging!

Author: Maarten Balliauw on 29 May 2013