MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Welcome to BlogEngine.NET 3.0

If you see this post it means that BlogEngine.NET is running and the hard part of creating your own blog is done. There is only a few things left to do.

Write Permissions

To be able to log in, write posts and customize blog, you need to enable write permissions on the App_Data and Custom folders. If your blog is hosted at a hosting provider, you can either log into your account’s admin page or call the support.

If you wish to use a database to store your blog data, we still encourage you to enable this write access for an images you may wish to store for your blog posts.  If you are interested in using Microsoft SQL Server, MySQL, SQL CE, or other databases, please see the BlogEngine docs to get started.

Security

When you've got write permissions set, you need to change the username and password. Find the sign-in link located either at the bottom or top of the page depending on your current theme and click it. Now enter "admin" in both the username and password fields and click the button. You will now see an admin menu appear. It has a link to the "Users" admin page. From there you can change password, create new users and set roles and permissions. Passwords are hashed by default so you better configure email in settings for password recovery to work or learn how to do it manually.

Configuration and Profile

Now that you have your blog secured, take a look through the settings and give your new blog a title.  BlogEngine.NET is set up to take full advantage of many semantic formats and technologies such as FOAF, SIOC and APML. It means that the content stored in your BlogEngine.NET installation will be fully portable and auto-discoverable.  Be sure to fill in your author profile to take better advantage of this.

Themes, Widgets & Extensions

One last thing to consider is customizing the look and behavior of your blog. We have themes, widgets and extensions available right out of the box. You can install more right from admin panel under Custom/Gallery.

On the web

You can find news about BlogEngine.NET on the official website. For tutorials, documentation, tips and tricks visit our docs site. The ongoing development of BlogEngine.NET can be followed at CodePlex where the daily builds will be published for anyone to download.

Good luck and happy writing.

The BlogEngine.NET team

Promoting packages generated during build

We’ve supported the “Push upstream” workflow for quite a while now. This workflow allows you to promote packages from one feed to another, ideal when you are pushing prerelease packages on one feed and pushing them as stable packages to another feed after testing them.’

So far, it has been only possible to push individual packages upstream, or all “latest” packages. We realized this was painful for one scenario: if you’re usign Build Services, it may be handy to be able to push just the packages generated by a specific build. And that is exactly what we’ve added now!

Promoting packages generated duing build

When expanding a build’s packages, a new menu entry Push upstream…is now available to push the packages generated by a build to another feed. This should greatly improve usability for this scenario.

Happy packaging!

Package details now showing update notification

When you create a MyGet feed, chances are you want to keep the packages up to date. This can be done automatically by enabling auto-update on the package sources for your feed, but that is not always desired. Some people prefer updating individual packages manually, which makes perfect sense: only packages you approved will be available on the feed.

To help detecting package updates, we’re now showing a notification on the package details page whenever any of the configured upstreampackage sources has a newer version available. With just one click, we can update the package and its dependencies.

Package update notifications

Give it a try on your MyGet feed!

Happy packaging!

Creating a license report for your NuGet feed

When managing your dependencies using MyGet, it may be important to have a view on which licenses are used on your feeds and in your software projects. Which licenses are your NuGet packages using? Many teams would love to know which (open source) licenses are being used by their teams, so they can be inspected and managed. It feels good to finally tackle one of those items that have been on our backlog for almost two years: we now support this exact scenario!

Note: this feature is only available for paid subscriptions.

From your feed, a new Licenses tab should now be visible showing a report of all licenses used by packages on your feed.

NuGet license analysis report

The licenses overview gives you a chart that provides a quick view on licenses in use. The list underneath shows all different licenses used per package identifier. If a package changed license over time, it will be listed twice. To quickly filter the detailed list, simply click one of the colors in the chart: this will show just the packages that have the selected license applied.

Where does license information come from?

Whenever a package is uploaded to your feed, whether from an upstream package source or by using nuget push, MyGet will perform a license analysis on the package. The license is determined as follows:

  • If we’ve seen the package’s license URL before, we will assign the same license to the package that is being added.
  • If your feed contains a package with the same identifier, we’ll take that package’s license.
  • If we haven’t, we’ll download the license URL result and run a full-text analysis on it. We’ve been working on a unique scoring algorithm which compares the text with known OSI licenses out there.
  • If the score is too low, we assign the license “Unknown” to the package.

Can I change licenses for a package?

Absolutely! Whenever you have a package where the license analysis was incorrect, or you have a proprietary package which has a unique license name, it is possible to assign it to a package. From the package details page, you can inspect the package license as well as override it.

View individual package license

Editing the license will open a dialog in which you can edit the license. We’ll provide autocompletion on known OSI licenses, but if you have a proprietary license name that can be entered here as well. Once a license has been overriden, new versions of the package will be assigned the overriden license.

Override NuGet package license

We’re eager to hear your feedback on this feature!

Happy packaging!

Package mirroring is now enabled by default

Any service can experience a brief moment of downtime. This is also true for any upstream package source you configure in MyGet. That's why we have the package mirroring feature: when uploading or adding a package to your feed, the added package (and its dependencies) are stored into MyGet's own storage system and they remain available in the event of an upstream service outage.

This package mirroring checkbox used to be disabled by default. Why? Because we wanted to save on storage costs. You might think we were being cheap here, but today we are hosting over 50Gb of packages and serving many of them multiple times a day! In the early days of MyGet, it made sense to simply reference the packages from eg. nuget.org and redirect you to the package URL upstream. This has saved us quite some storage, bandwidth and backup costs whilst bootstrapping (you know the Free plan isn't free for us, right?).

However, as we are maturing, we also gain new insights in how you are using MyGet so we can more effectively reduce friction in the way you work with packages. We measured that 95% of our users are mirroring their packages, so we are now reversing the logic for it. As of today, the checkbox will be checked by default!

A popular question we get is: why aren't you hosting an entire mirror of nuget.org? Answer: this is another one of those backlog items that has been sitting around for years, and we believe NuGet API v3 will greatly facilitate such scenario. One day :)

Happy packaging!

Announcing Visual Studio Online integration

We are really excited to announce that as of today, MyGet enables new scenarios for all users of Visual Studio Online! Microsoft just announced Visual Studio Online Extensions at TechEd, so we can finally disclose these new scenarios and toggle the feature-switch for all of you.

In short, these are the new scenarios we've just enabled for you:


New to MyGet? Interested in using the Visual Studio Online integration? Why not make use of our TechEd 2014 offer that gives you a complimentary 2-month Starter plan!

New Scenario: Serve NuGet packages from a Visual Studio Online drop location

Having a VSO Build Definition creating NuGet packages but having trouble consuming those? You can now very easily create a MyGet feed and serve those NuGet packages by having us fetching them from your Drop Location! Optionally, we can post notifications to your VSO Team Room so your team gets informed about new package availability as the result of your automated builds.

Package sources could be considered as upstream repositories for your MyGet feed, which is how you can look at the VSO Build Drop Location. The following simplified diagram provides a schematic overview of this new integration scenario.


All you need to do to make us of this integration is to add a new package source to your MyGet feed:

  1. Go to your feed's settings and select the Package Sources tab. Select Visual Studio Online build definition from the Add package source button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the Team Project and Build Definition to add as the package source for your feed. Optionally, select the Team Room in which to post notifications. Click the Add button to complete the configuration of the new package source.

  4. The new VSO package source has been added to your feed's package sources, and newly built NuGet packages will be fetched from your Drop Location automatically and pushed to the MyGet feed.

New Scenario: Add a VSO Git repository as a Build Source for a MyGet feed

This is the same scenario we already support today for GitHub, BitBucket and Codeplex: you can now register MyGet Build Services as a post-commit hook to your VSO Git repositories. We are happy to provide an integrated VSO experience from within MyGet, but even happier to also have a MyGet service hook available within the VSO user interface! Whether you use the VSO user interface or MyGet web site, you can enable this scenario from within both.

Build sources are a way to express links between MyGet Build Services and your source repositories, whether on GitHub, BitBucket, Codeplex or now also on Visual Studio Online. The following simplified diagram provides a schematic overview of this new integration scenario.

Note: we currently only support Git repositories, TFVC support is on the roadmap.


Here's a step-by-step guide on how to register a VSO Git repository within MyGet Build Services.

  1. Go to your feed's settings and select the Build Services tab. Select from Visual Studio Online (git only) from the Add build source… button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the desired build source to link and optionally enable notifications in a specific Team Room. Click the Add button to complete the configuration of the new Build Source.

  4. The new VSO build source has been added to your feed's build sources, and a post-commit service hook has been registered within VSO. When pushing to your VSO Git repository, a new MyGet build is going to be triggered and will produce your NuGet packages and push them to your feed.

    If you look at your Visual Studio Online Administration dashboard and browse your Team Project's Service Hooks, you'll see a newly registered web hook listening for the Code is pushed event.

New Scenario: Connect an existing MyGet Build Source to Visual Studio Online

Alternatively, you can also setup MyGet integration from within Visual Studio Online. This is useful if you already have an existing MyGet Build Source pointing to your VSO Git repository and triggered it manually up until now. You should be glad to hear you can now connect these and automate that.

  1. Go to your VSO Team Project Administration dashboard and select the Service Hooks tab.
  2. Click the Add Service Hook button

  3. Within the New Service Hooks Subscription dialog, select the MyGet service and click the Next button.

  4. Select the Code is pushed event type and the desired Repository and Branch settings. Click Next to continue.

  5. Select the Trigger a MyGet build action and provide the target Feed name and Build Source Identifier.

    You can find the Build Source identifier in your MyGet feed settings > Build Sources, as highlighted below:

  6. Click Test if you want to test this service hook first, or click Finish to complete the wizard. The new service hook is now listed as shown below:

We aim to please

We hope you are happy with this brand new VSO support and will put it to good use! We'd also like to express our gratitude to the Microsoft VSO team for enabling this type of extensibility as well as guiding us through this integration effort. A smooth, integrated user experience to reduce development friction is one of our main goals, and we hope these scenarios will prove to be a great help.

Feel free to send us your feedback or feature requests!

Happy packaging!

Picking the right dependency version adding packages from NuGet.org

Since NuGet 2.8, the NuGet Package Manager Console’s Install-Package command comes with support for specifying the dependency version resolution process using the –DependencyVersion switch. If you have never used it before, what it does is it allows you to specify how NuGet should resolve package dependencies. It can resolve dependencies to the lowest possible version (default behavior), the highest possible version, or the highest minor or patch version.

This feature is useful because it gives you control over how dependencies are resolved. For example, when package A has a dependency on package B >= 2.0 and available versions of package B are: 1.0, 2.1.1, 2.1.2, 2.2.1, 2.2.2, 3.0.1, 3.0.2, the version of package B that will be resolved will be:

  • 2.1.1, when DependencyVersion is Lowest
  • 2.1.2, when DependencyVersion is HighestPatch
  • 2.2.2, when DependencyVersion is HighestMinor
  • 3.0.2, when DependencyVersion is Highest
Word of warning: changing the default behaviour may break package dependencies. In theory, only the lowest defined version number is sure to work. If a dependency is specified for packages >=1.0.0, using DependencyVersion Highest would potentially bring in version 7.0.0 which may not work for the package depending on it. Use with caution!

If you are interested in always having the latest versions of a dependency within a given mayor version, the HighestMinor setting will actually do that. This can be done from the Visual Studio Package Manager Console:

NuGet select dependency version resolution strategy

This can also be set as a default for all NuGet packages installed by editing the NuGet.config file or using NuGet configuration inheritance:

<configuration> <config> <add key="DependencyVersion" value="HighestPatch" /> </config> </configuration>

When adding packages from an upstream feed like NuGet.org or a TeamCity server to a MyGet feed, this setting is available as well:

Specify DependencyVersion switch with MyGet

This should greatly help in getting your preferred packages installed instead of having to install and manually update dependency versions to the required version for your project. For more information about the DependencyVersion switch, do check the NuGet documentation.

Happy packaging!

Configuring password policies and account lockout using MyGet Enterprise

MyGet Enterprise contains everything MyGet has to offer, hosted on a dedicated URL for your team. It comes with an additional management dashboard that can be used to manage everything related to the team such as feeds, users, quota, account policies and so forth. We recently made some additions to this mangement dashboard that make managing a MyGet Enterprise account even more powerful.

Managing account policies for MyGet EnterpriseWhen navigating to the management dashboard as an administrator, you will be greeted by a new menu entry: Account. This section allows access to management of:

  • Password requirements, such as
    • Minimum password length
    • Required lowercase characters
    • Required uppercase characters
    • Required numeric characters
    • Required special characters
  • Lockout policy
    • How many invalid login attempts are allowed? In what timeframe?
    • How long should accounts be locked out?
  • Session
    • After how much idle time should users be logged off?

We also added the ability to unlock users from the Users section. This way you can also manually unlock users within your team if required.

Speaking of the Users section… Many teams wanted to have the ability to have an administrator create users insted of waiting for users to register their own account. Users can now be created by clicking the Add a new user button, after which the display name, user name, password and e-mail can be entered. Optionally, a welcome e-mail can be sent to the user as well.

Full documentation on the MyGet Enterprise management dashboard is available as well.

Happy packaging!

Using MyGet as a OneGet package source

At the Build conference, Microsoft announced the Windows Management Framework 5.0 Preview which includes Windows PowerShell 5.0, updates to the PowerShell ISE, Network Switch Cmdlets and ... OneGet!

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.

The OneGet team also has a weekly community meeting of which you can see the first introductionary recording below.

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: a a unified interface to package management systems (see above)

So what does this mean? How do these package managers play along?

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 blow diagram is an attempt to illustrate how they relate:

How do OneGet, Chocolatey, NuGet and MyGet play along?

OneGet supports several commands at this stage:

OneGet Preview cmdlets

How can I use a private OneGet package source?

So how can I register a private OneGet package source? Well, let's first see how you can register any package source using the Add-PackageSource cmdlet. Here's what the built-in help currently says:

OneGet Add-PackageSource Help

Note that this is a Preview: help is incomplete and cmdlets might change name, but this should already give you a good idea of what you can do with this cmdlet!

Now, let's register a MyGet feed on which you can host Chocolatey packages:

Register a MyGet feed as a OneGet package source

Did you notice how OneGet asked you to install the NuGet package manager?

That went easy right? That's because that feed was public :) OneGet does not support basic-authentication at this point, nor does it leverage any nuget.config settings you might configure (tried it). However, MyGet just added the possibility to use a "private-by-obscurity" endpoint on private feeds, which should allow you to use private feeds as well. Note: we don't actively promote this, as it requires you to share one of your feed's access tokens. This is a work-around for clients that don't support the basic-auth flow, and we'd prefer to have proper basic-authentication support in OneGet, so fingers crossed!

You can verify the correct registration of your OneGet package source using the following commands:

Get OneGet package sources List available packages on a OneGet package source

Installing a software package from this MyGet feed is straightforward as well:

Install a software package from a specific OneGet feed

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! :)

Receive feed activity notifications through RSS

Ever wanted to get notified when a new package is available on your feed? Did you know you can just browse the Packages collection on any NuGet feed?


Obviously, that also works on MyGet feeds, but did you know that ever since we launched MyGet, we had this little RSS endpoint sitting around?


In it's early state it was just exposing your feed's OData Packages collection. However, as we introduced activity logs and started collecting this data to show up in activity streams on the web site, we can now also provide you with a more useful RSS feed.

Wouldn't it be useful if we just gave you your activitylog through RSS? Let's see what it looks like in it's current form:

We think this is pretty useful. This is only a minimum-viable notification system in our opinion and we'd love to get feedback on how we can improve this further to match your needs. So please, don't hesitate to reach out and let your voice be heard! One address: http://myget.uservoice.com.

Besides simply subscribing to the RSS feed, you might want to make the internet work for you.

Our friends at MessageHandler have built something that hooks into our activity streams, allowing you to configure a handler that sends you an email and creates a GitHub issue when a MyGet build fails.

For those using IFTTT (if-this-then-that), we've also created a few recipes (or you can build your own):

Happy Packaging!