nupackpackages Wiki Rss Feed

Updated Wiki: Home

davidebbo — Wed, 12 Jan 2011 01:59:47 GMT

This site is now obsolete! Please use http://nuget.org to submit packages now!

Read this post for details.

Old content follows, only for reference

Welcome to the temporary NuGet package repository site

This is a temporary repository for NuGet packages while NuGet is in a pre-release state. By the time it reaches RTM, we’ll have a nice Gallery site with all the bells and whistles, but for now this is what our public feed is driven off.

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuGet repository, which has the sources for the NuGet engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Packages live under the PackageSources folder. Specifically, you need to create a [PackageName]\[PackageVersion] under that. e.g. Elmah 1.1. is under PackageSources\elmah\1.1. I’ll refer to this as your root package folder.

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuGet console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuGet console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuGet to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Wed, 12 Jan 2011 01:59:20 GMT

This site is now obsolete! Please use http://nuget.org to submit packages now!

Read this post for details.

Welcome to the temporary NuGet package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuGet repository, which has the sources for the NuGet engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuGet console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuGet console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuGet to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

Haacked — Tue, 21 Dec 2010 17:26:57 GMT

Welcome to the temporary NuGet package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuGet repository, which has the sources for the NuGet engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuGet console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuGet console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuGet to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

erichexter — Fri, 03 Dec 2010 04:40:47 GMT

Welcome to the temporary NuGet package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Sat, 20 Nov 2010 09:55:27 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Fri, 12 Nov 2010 19:22:31 GMT

Welcome to the temporary NuPack package repository site

This is a temporary repository for NuPack packages while NuPack is in a pre-release state. By the time NuPack reaches RTM, we’ll have a nice Gallery site with all the bells and whistles, but for now this is what our public feed is driven off.

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
Important: you don't need to merge with main. Many people do it in the wrong direction, which then needs to be fixed. We'll do the merge when we accept the pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Thu, 04 Nov 2010 16:35:07 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Thu, 04 Nov 2010 16:34:24 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Thu, 14 Oct 2010 00:47:45 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Also, please read through this page for info on creating packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Wed, 13 Oct 2010 21:22:51 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here. See all this page.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

Haacked — Wed, 13 Oct 2010 05:21:56 GMT

Welcome to the temporary NuPack package repository site

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Tue, 12 Oct 2010 07:57:57 GMT

Welcome to the NuPack package repository site

This is a repository for NuPack packages. In the longer term, we’ll have a nice Gallery site with all the bells and whistles, but for now this is what our public feed (http://go.microsoft.com/fwlink/?LinkID=199193) is driven off.

Here is what you need to do to contribute packages:

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Tue, 12 Oct 2010 07:45:49 GMT

Project Description

Here is what you need to do to contribute packages.

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here.

You will then make your changes in your fork

Add your new package files into the PackageSources folder

Tip: the best way to learn the correct layout is to look through existing packages. Here are the basics:

Directly in your root package folder, create a [PackageName].nuspec file (e.g elmah.nuspec). Start by copying one from another package!
Make sure you specify all your dependencies in the nuspec files. e.g. you at sparkmvc.nuspec. Please avoid including your dependencies inside your own package, as that defeats the purpose of dependencies. e.g. if your package uses Castle.Core, don’t include those dlls in your package, but take a dependency on the Castle.Core package!
Put your assembly references under a lib folder. They can either be directly under lib, or in a subfolder if they’re framework version specific. e.g. folders can be names ‘2.0’, ‘3.5’, ‘4.0’, ‘SL4’ (for Silverlight).
You don’t need to add any entries into your NuSpec file to point to those lib files. Being in lib is all it takes to have them treated as references.
Put your content files in the Content folder. These are files that will get copied into the project when the package is installed.
If your package contains tools, put then in the Tools folder. If you include .exe files, they’ll end up being on the path in the NuPack console.

Build the packages and test your package

Go to the root of the NuPackPackages repo and run RebuildPackages.cmd. This will build all the .nupkg files into a NuPackPackages folder (i.e. NuPackPackages\NuPackPackages).
In VS, go to the NuPack console (aka Package Manager Console), and click the icon to the right of the Package Source to add a new Package source
Add a new Package Source using the local path to the folder that has the .nupkg files. e.g. D:\NuPackPackages\NuPackPackages
You can now use NuPack to try installing your package. Test it well to make sure it works the way you want!

Send a pull request

When you’re happy with your package, push your changes to your fork and send a pull request
In the pull request, please include your twitter name so we can easily ping you. Also include some info about what you’re adding.
If all goes well, your package will be in the feed in a few hours

Updated Wiki: Home

davidebbo — Tue, 12 Oct 2010 07:16:27 GMT

Project Description

Here is what you need to do to contribute packages.

Fork the nupackpackages repository

Note that this is a different repository from the NuPack repository, which has the sources for the NuPack engine. This one just contains packages.

Just go to the Source Code repository and create a fork. If you’re unfamiliar with Mercurial, start here.