MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Working with scoped npm packages and MyGet private registry

When we introduced npm support on MyGet last month, we did not yet have support for scoped packages. Today, we’re pleased to announce full support for them!

Scoped packages are packages that are "scoped" to a specific registry. E.g. all packages scoped @acmecorp may be retrieved from a MyGet npm registry feed, while other scopes and non-scoped packages flow in from the default npm registry.

Creating a scoped package

A scoped package can be created by setting the name property in package.json file correctly, for example:

{
  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0"
}

Dependencies can be scoped as well:

{
  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0",
  "dependencies": {
    "@acmecorp/awesomepackage": "1.0.0"
  }
}

More information on scoped packages is available from the npm docs.

Publishing a scoped package

Scopes can be associated with a specific registry. This allows for seamless mixing of packages from various npm registries.

Let's associate the scope @acmecorp with the https://www.myget.org/F/your-feed-name/npm/ npm registry feed. We can do this manually, by adding the following to our .npmrc file:

@acmecorp:registry=https://www.myget.org/F/your-feed-name/npm/
//www.myget.org/F/your-feed-name/npm/:_password="base64encodedpassword"
//www.myget.org/F/your-feed-name/npm/:username=someuser
//www.myget.org/F/your-feed-name/npm/:email=someuser@example.com
//www.myget.org/F/your-feed-name/npm/:always-auth=true

It's probably easier to generate these entries from the command line by running:

npm config set @acmecorp:registry=https://www.myget.org/F/your-feed-name/npm/
npm login --registry https://www.myget.org/F/your-feed-name/npm/ --scope=@acmecorp
npm config set always-auth true --registry https://www.myget.org/F/your-feed-name/npm/

From now on, we can publish and consume any package that has the @acmecorp scope. Npm will automatically direct requests to the correct registry.

Happy packaging!

P.S.: We have VSIX support coming as well. Let us know if you want to enroll in the preview.

Limited preview - VSIX support

MyGet has a rich feature set for NuGet, and we just recently added support for Bower and NPM registries. Now we'd like to give our users the opportunity to bring those rich MyGet features to VSIX as well!

What VSIX support will you get in this preview?

We currently have the full feature set we already have for NuGet, Bower and NPM. You'll be able to manage extensions, add them from upstream feeds (ATOM only), granular permissions and user management, support for community feeds... If you need a staging feed or just a private VSIX gallery, this is the easiest way to get one. Using the VSO integration? We'll pick up the VSIX artifacts from your VSO build and automatically add them to your MyGet VSIX feed.

I want to join the preview!

If you are interested in joining the private preview and eager to provide some early feedback, then just ping us with your username and we'll flip the feature toggle for your account.

MyGet now offers NuGet, Npm and Bower registries

pmsWith our latest MyGet release, we’ve added support for npm and bower registries. We’ve always been very focused on building a great story around NuGet and decided it was time for Npm and Bower enthusiasts to get a similar experience.

Adding npm and Bower support was high on our wish list and that of our users. Many developers are doing only front-end development and need a public or private npm registry. Others are working with DNX (the new name for ASP.NET 5 or ASP.NET vNext) and combine NuGet, npm and Bower. It feels good to be able to support them all!

To help you get started, we’ve prepared a few short tutorials that help you get started on MyGet with these package managers:

Oh and build services now also packages node modules! Just point MyGet to your GitHub repository and we’ll package your npm packages, too.

We really look forward to hearing your feedback on this!

Happy packaging!

MyGet 2.0 Release Notes

MyGet 2.0 was released on March 12, 2015.

Highlights

This 2.0 release of MyGet adds brand new functionality to the service. With this release, we bring all the functionality we already had for NuGet also to Bower and NPM!

This means, from now on, you can use MyGet to host and build your own NuGet, NPM or Bower feeds, whether public or secured.

Features

MyGet (all plans)

The following applies to all MyGet plans:

MyGet (paid plans)

Obviously all paid plans also get the enhancements made available on the free plan. The following applies to the MyGet Starter and Professional plans:

MyGet Enterprise

The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:

MyGet Build Services

Bug Fixes

  • Improved detection of hanging builds
  • Build now properly fails when compilation fails and no packages have been produced or pushed to your feed
  • Upstream package source proxying enhancements
  • No longer prompt the user that a package update is available upstream if the package source is set to auto-update

Keep that feedback coming! MyGet is built for you!

Happy packaging!


Introducing MyGet Feed Sync

How can you keep multiple local NuGet servers synchronized? How can developers consume the same packages when each office branch has its own local NuGet server? How can two servers be synchronized when bandwidth is insufficient for a cloud-only solution?

We’re happy to introduce Feed Sync. Jointly developed by MyGet and Inedo ProGet, allows you to synchronize packages on multiple package servers with MyGet.

Note: During preview, Feed Sync is available for all MyGet plans and Inedo ProGet free users. After release, Feed Sync will be available for all paid MyGet plans and users of ProGet Enterprise 3.5 and up.

Synchronize local NuGet server with MyGet

Packages added on a linked ProGet instance will be replicated to MyGet and any other linked instance. When using MyGet Build Services to build packages from GitHub, BitBucket or Visual Studio Online, packages that are created will be replicated as well.

Read up on how to configure Feed Sync in our documentation.

Happy packaging!

Modify NuGet package description and release notes before pushing upstream

Ever enjoyed watching your builds go green to find out that the packages created had a typo in the description? Or you simply forgot to add release notes? Very annoying if you simply want to push your packages out there!

This annoyance triggered one of our dear customers to send us a feature request: "What if I could modify these fields before I hit the Push button?" Well, we thought that was indeed a great idea, so we implemented it, whilst we also gave the UI a little more love :-)


If you click the Edit button next to each package, you'll now have the ability to modify the pre-release tag, the package description, and the package release notes. With a click of a button, you can also apply the release notes to all packages listed in the dialog. 


And to finish it off, we support markdown in the release notes. Packages that have release notes which contain markdown will be rendered nicely on the package details page.

Happy Packaging!

IP whitelisting for MyGet Enterprise customers

Many enterprises access the Internet using one or more static IP addresses and prefer limiting access to their applications to those IP addresses. Good news: MyGet Enterprise customers can now whitelist IP addresses (or IP ranges) so only clients can only access MyGet if they are coming from the configured address. The whitelist will be applied for accessing the website, as well as for consuming hosted NuGet feeds.

IP whitelisting for MyGet Enterprise customers

Enterprise administrators can navigate to the administration dashboard, and create an IP whitelist under the Accounts tab. IP addresses can be entered on separate lines. If an entire subnet has to have access, the IP address can be suffixed with a CIDR suffix (e.g. /24) or a subnet mask (e.g. /255.255.255.0).

Happy packaging!

Black Friday Sales - 30% discount on MyGet Starter and Professional

Thank you! Black Friday dealsWhile in Europe we don’t have holidays this week, we do want to share the tradition of Thanksgiving. MyGet could have never grown into what it is today without you. We'd like to thank you by having a sale on our Starter and Professional plans!

Starter and Professional Subscriptions of 6 months get a 15% discount. If you decide to stay with us for a full year, we’ll give you 30% off!

Interested? Sign in to your MyGet account and create a new subscription or extend your existing one.

Since today is “Black Friday” and right after the weekend is “Cyber Monday”, we’re keeping this sale available until Tuesday December 2nd, 2014. This gives ample opportunity to purchase a MyGet subscription at a discounted rate.

Happy packaging!

PS: Give our new features a try, too. We have service messages support, more web hooks and a load of other things!

Could not load file or assembly… NuGet Assembly Redirects

When working in larger projects, you will sometimes encounter errors similar to this one: “Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.” Or how about this one? “System.IO.FileLoadException : Could not load file or assembly 'Moq, Version=3.1.416.3, Culture=neutral, PublicKeyToken=69f491c39445e920' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Search all you want, most things you find on the Internet are from the pre-NuGet era and don’t really help. What now? In this post, let’s go over why this error sometimes happens. And I’ll end with a beautiful little trick that fixes this issue when you encounter it. Let’s go!

Redirecting Assembly Versions

In 90% of the cases, the errors mentioned earlier are caused by faulty assembly redirects. What are those, you ask? A long answer is on MSDN, a short answer is that assembly redirects let us trick .NET into believing that assembly A is actually assembly B. Or in other words, we can tell .NET to work with Newtonsoft.Json 6.0.0.4 whenever any other reference requires an older version of Newtonsoft.Json.

Assembly redirects are often created by NuGet, to solve versioning issues. Here’s an example which I took from an application’s Web.config:

<?xml version="1.0" encoding="utf-8"?> <configuration> <!-- ... --> <runtime> <legacyHMACWarning enabled="0" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

When running an application with this config file, it will trick any assembly that wants to use any version < 6.0.0.0 of Newtonsoft.Json into working with the latest 6.0.0.0 version. Neat, as it solves dependency hell where two assemblies require a different version of a common assembly dependency. But… does it solve that?

NuGet and Assembly Redirects

The cool thing about NuGet is that it auto-detects whenever assembly redirects are needed, and adds them to the Web.config or App.config file of your project. However, this not always works well. Sometimes, old binding redirects are not removed. Sometimes, none are added at all. Resulting in fine errors like the ones I opened this post with. At compile time. Or worse! When running the application.

One way of solving this is manually checking all binding redirects in all configuration files you have in your project, checking assembly versions and so on. But here comes the trick: we can let NuGet do this for us!

All we have to do is this:

  1. From any .config file, remove the <assemblyBinding> element and its child elements. In other words: strip your app from assembly binding redirects.
  2. Open the Package Manager Console in Visual Studio. This can be done from the View | Other Windows | Package Manager Console menu.
  3. Type this one, magical command that solves it all: Get-Project -All | Add-BindingRedirect. I repeat: Get-Project -All | Add-BindingRedirect

NuGet Add Binding Redirect

NuGet will get all projects and for every project, add the correct assembly binding redirects again. Compile, run, and continue your day without rage. Enjoy!

PS: For the other cases where this trick does not help, check Damir Dobric’s post on troubleshooting NuGet references.

Build Services - Introducing pre- and post-build steps

With our 1.9.5 release out of the door, we’ve introduced support for pre- and post-build steps in MyGet Build Services. When using batch / PowerShell based builds for building your GitHub, BitBucket or Visual Studio Online projects and making NuGet packages for them, MyGet Build Services will scan for batch files to be executed. In addition to the default build.bat (or .cmd or .ps1), we search for pre- and post-build steps as well. These can be batch scripts or PowerShell scripts that are run before and after the actual build file.

When using MyGet Service Messages in the build, pre- and post-build steps can be used to prepare the build environment by setting the correct package version number, or creating additional environment variables for use by the build script.

More information can be found in our docs.

Happy packaging!