-
Notifications
You must be signed in to change notification settings - Fork 0
Nuget
OpenWrap provides a best-effort support of NuGet packages and feeds. The currently known valid NugetFeed URL is
nuget://packages.nuget.org/v1/FeedService.svc/Packages
, but OpenWrap keeps a marker to this url internally, named 'nuget'.You can add any NuGet feed to OpenWrap by adding the feed containing all OData packages as a remote repository, using the special @nuget@ scheme.
For the RTM feed of NuGet, you can use the following command.
$ o add-remote nuget
You can verify that packages are available by listing packages from the newly added remote.
$ o list-wrap -remote nu
#Converting a NuGet package
A NuGet package can be converted to an OpenWrap one by using the convert-nuget command, that takes the path to the nuget package you want to convert.
$ o convert-nuget path/to/package.nuget
An OpenWrap package will be created in the same location with the same name, with the simpler and more elegant OpenWrap format.
Nuget specifications get converted to the OpenWrap format the first time you import a package. Most useful elements are being imported and will work as usual, except for the following.
Because OpenWrap does not depend on powershell, install scripts written in PowerShell are not executed at this time.
Any script depending on the DTE object also relies on Visual Studio for package installation, and that is not something we believe is a good idea for a package manager, so that's not supported either.
NuGet does not currently support dependency levelling, while OpenWrap does. This means that your package adds may automatically downgrade a package to a compatible version. So if you see different package versions in use than the ones NuGet would come to, that would be one reason.
Another difference between NuGet and OpenWrap is more conceptual, and deals with range of supported versions for a dependency.
Say a package declares in NuGet a dependency on nhibernate 2.1.0. The default range generated by NuGet for this dependency would be nhibernate >= 2.1.0. As soon as nhibernate 3.0 gets released, this means that it would now be valid for that package to use nhibernate 3.0
As anyone dealing with new versions of assemblies know, this would immediately break. The way NuGet compensates for that is by also relying on the implementation details of their package resolution algorithm.
Compensating for defaults that provide incompatible package version ranges by documenting implementation-specific behaviour is not only unreliable, it also prevents any changes to the dependency resolution algorithm, and breaks systems like OpenWrap that resolve packages differently.
As such, OpenWrap automatically converts 2.1 to depends: nhibernate = 2.1 and 2.1.1 to depends: nhibernate >= 2.1 and < 2.2.
The maven-style dependency ranges are however supported and will provide the same defaults.
The algorithm for NuGet is described on their codeplex site. OpenWrap resolves packages differently, by selecting the highest possible version of a dependency when adding or updating packages.
Another difference comes from "hot patches". NuGet will automatically apply a semver.org-like algorithm to upgrade your packages. If you have a dependency specifying version 2.1.0 of a package, they assume that any upgrade to 2.1.x will be compatible.
OpenWrap lets package authors and yourself be in control of the auto-update behaviour. If you want to be updated automatically to any 2.1.x, you declare a dependency on 2.1.
What we do support is automatically updating any revision, to support hot-patching mechanisms. If you declare a dependency on 2.1.0.1, the last part will be ignored and any 2.1.0.x version will get updated.
Unlike NuGet, OpenWrap by default adds references to all assemblies in all the packages you have added to all your projects. The reason is simple: if you don't use a type from an assembly, the C# compiler will not add the reference in the compiled assembly. There is no reason to only add a reference to only one project, as long as you don't use the types the reference will not be ever in the compiled assembly.
That said, there is a way to exclude certain assemblies from the import a project receives. See consuming-wraps-from-MSBuild for the list of changes you can make to a specific project.
The other feature that will get implemented post v1 is the idea of "configurations", where you can define different sets of dependencies for different configurations, and the ability to run a package in a different configuration. The feature has been mostly designed but hasn't been implemented yet.