Creating a new project with OpenWrap

With all this discussion of OpenWrap stuff, we’ve not covered yet how easy it is to create a new project in OpenWrap and get it off the ground.

For OpenWrap to function, you don’t need much. You need a /wraps folder at the root of your code, a descriptor file, and optionally a version file.

Creating a new package

The easiest way to create a new project is to use the init-wrap command with a name for your new package or project. As I use git, I’ll also ask it to generate the .gitignore files for me.

<div><strong>PS C:\src></strong><i> o init-wrap newProject -git</i></div>
# OpenWrap v1.0.0.0 ['C:\Users\sebastien.lambla\AppData\Local\OpenWrap\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
Specify either the path to the projects you want updated or -all to find all projects automatically.
Copying 'openwrap-' from 'System repository' to 'Project repository'
Copying 'openfilesystem-' from 'System repository' to 'Project repository'
Copying 'sharpziplib-' from 'System repository' to 'Project repository'
Package 'newProject' initialized. Start adding packages by using the 'add-wrap' command.

Your project structure is now going to be fully created, together with ignore files and the first couple of packages you need.

Adding a new project

imageNow you can go and open Visual Studio, and create a new project in the /newProject/src folder that was created earlier. Any will do, I’ll add a new bog standard “Class Library” project and name it NewProject.Core.

Note that you can use any C# project type, OpenWrap doesn’t care much. VB and other languages can be supported, as soon as someone ask for them we’ll add that.

One of the things that makes OpenWrap different is also that you can create a Visual Studio 2008 or Visual Studio 2010 project, it doesn’t matter either. And you can choose a .net 2, .net 3.5 or .net 4 project type, it will all still work.

OpenWrap, meet Project, Project, meet OpenWrap

Next, we need to inject OpenWrap in the build process of that project. Again, not much to do there, it’s a one-liner. Go into the folder you created earlier, and execute the init-wrap command with the -all parameter. This instructs OpenWrap to find all ‘.csproj’ files and update them.

<div><strong>PS C:\src></strong><i> cd newProject</i></div>
<div><strong>PS C:\src\newProject></strong><i> o init-wrap -all</i></div>
# OpenWrap v1.0.0.0 ['C:\src\newProject\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
Package descriptor found.
Project 'C:\src\newProject\src\NewProject.Core\NewProject.Core.csproj' updated to use OpenWrap.

If you return to Visual Studio, you’ll be greeted by a dialog box letting you know the project was modified. Reload it, and you’ll be ready to go.

Writing some code

We’ll write a log4net class in our newly-created project.

  1. namespace NewProject.Core

  2. {

  3. public class Appender : log4net.Appender.TextWriterAppender

  4. {


  1. }

  2. }

As you can see, ReSharper tells us it doesn’t recognize that class. Let’s add the package for log4net.

<div><strong>PS C:\src\newProject></strong><i> o add-wrap log4net</i></div>
# OpenWrap v1.0.0.0 ['C:\src\newProject\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
Wrap descriptor found.
Project repository present.
Dependency added to descriptor.
Copying 'log4net-1.2.10' from 'nu' to 'System repository'
Copying 'log4net-1.2.10' from 'nu' to 'Project repository'
Making sure the cache is up-to-date...

If you now go back to your solution, you’ll notice that the red lining is now gone, and you can build your code as if you had added the reference yourself. If you don’t use Resharper, rebuild your project as normal and see that the code compiles.

Packaging a package

You now have functional code you’re happy with, and you want to share your package. Fear not, for again, it’s a one-liner.

<div><strong>PS C:\src\newProject></strong><i> o build-wrap -quiet</i></div>
# OpenWrap v1.0.0.0 ['C:\src\newProject\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
Output found - bin-net40: 'C:\src\newProject\wraps\_cache\log4net-1.2.10\bin-net20\log4net.xml'
Output found - bin-net40: 'C:\src\newProject\src\NewProject.Core\obj\Debug\NewProject.Core.dll'
Copying: bin-net40 - C:\src\newProject\wraps\_cache\log4net-1.2.10\bin-net20\log4net.xml
Copying: bin-net40 - C:\src\newProject\src\NewProject.Core\obj\Debug\NewProject.Core.dll
Package built at 'C:\src\newProject\newProject-'.

Note that I’ve used the -quiet parameter to silence the MSBuild output. You can of course see the whole output by simply removing that parameter.

Publishing a package

Only thing left to do to start sharing your code is to publish it. I use the Network Share feature for publishing my packages, so it’s dead easy.

<div><strong>PS C:\src\newProject></strong><i> o publish-wrap netshare .\newProject-</i></div>
# OpenWrap v1.0.0.0 ['C:\src\newProject\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
Publishing package 'newProject-' to 'netshare'

And I can verify that the package was indeed published properly by listing the packages in the remote.

<div><strong>PS C:\src\newProject></strong><i> o list-wrap -remote netshare</i></div>
# OpenWrap v1.0.0.0 ['C:\src\newProject\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
 - newProject (versions:

As always, don’t forget you can get help on each of those commands by using the get-help command.


Announcing OpenSpaceBeers, the open-space for all developers, whatever the platform

We’ve been running open-spaces for a while. It’s now time to build something new, and something that will hopefully benefit all communities.

OpenSpaceBeers are open-space monthly events, where the beer flows, the ideas fuse and the right questions get asked to all developers interested in contributing. It doesn’t matter if you’re .net, java, python, php, coldfusion, ruby, scala or basic. We all face the same issues, and there’s a lot of sharing to do.

A developer is a developer, whatever platform they’re on.

First OpenSpaceBeers is next Tuesday, 26th of October. Tickets are going to be released as follow. They will all be open at random times during the day.

  • Round 1: Today, 19th of October, 1PM
  • Round 2: 21st of October, 3PM
  • Round 3: 23rd of October, 6PM
  • Last chance: 25th of October, 9M.

Come and enjoy the best regular developer-focused event, in a relaxed pub environment.

Register on EventBrite now.


Contributing to OpenWrap

I’ve already detailed how to fork OpenWrap to your github account. Now you want to make some changes. Here’s a small guide of the main things you need to do, and a quick intro to git as well to make sure everybody can contribute.

[pre-emptive-strike] You should always use branching when working on something. This is a 5 minutes intro on how to get on with git, not a best-practice guide. [/pre-emptive-strike]

First things first, make sure your auto.crlf settings are set. This is important so the line endings stay the same across all developers, and** if you forget this, I won’t be able to take the pull request at all**.

In the directory in which you have your clone of OpenWrap, you can issue the following command.

<div><b>PS C:\src\openwrap></b><i> git config core.autocrlf false</i></div>

Now you can start working on the code. Once you have made the changes you want, you can build OpenWrap as simply as issuing the build command.

<div><b>PS C:\src\openwrap></b><i> o build-wrap</i></div>

Which you can then follow by updating your local copy of openwrap with another one-liner.

<div><b>PS C:\src\openwrap></b><i> o update-wrap</i></div>

Picking a task

Our issue tracker is at I’ve annotated a bunch of issues with self-explanatory tags, from bugs to easy to what we want before we call this release a 1.0.0 release.

When you have chosen something from that list, just add a comment to the github issue to let everyone know you’re working on it.

When you’re happy with your changes

Chances are, as you changed OpenWrap’s code, you probably updated your packages a couple of times. This leaves behind a couple of things you need to get rid off before doing a pull request.

First, each time you build, a new package is added to the current directory. Delete them all, as they don’t need to be in the repository.

<div><b>PS C:\src\openwrap></b><i> del *.wrap</i></div>

Now, you also want to clean-up old packages that are no longer in use. Again, it’s a one-liner.

<div><b>PS C:\src\openwrap></b><i> o clean-wrap</i></div>

You now should only have your changes in your current repository.

Making your commit and pushing

First, you can always have a look at the changed files you have using the git status command.

<div><b>PS C:\src\openwrap></b><i> git status</i></div>
# On branch edge
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#       modified:   src/OpenWrap.Commands/Wrap/PackageDescriptionOutput.cs
no changes added to commit (use "git add" and/or "git commit -a")

This shows you that you’ve changed a specific file.

You now just need to add those files to your staging area, aka the things you want to be committed back in your repository.

<div><b>PS C:\src\openwrap></b><i> git add src/OpenWrap.Commands/Wrap/PackageDescriptionOutput.cs</i></div>

Once that is done, you simply need to commit your changes. Make your git commit imperative and descriptive of what you’re doing. If you’re tackling an issue and you think you’ve solved it, use the close #xx text in your commit message, that will help close the issue you were trying to fix.

<div><b>PS C:\src\openwrap></b><i> git commit -m "Writes the nuke property of a pacakge in list. Closes #999."</i></div>

When you’re ready to publish to github what you have, you simply need to do a push.

<div><b>PS C:\src\openwrap></b><i> git push origin master</i></div>

This will publish your code for all to see.

Sending a pull request

You are now nearly ready to become a full fledged OSS contributor. The only thing left is to send your changes to the upstream project so they can have a look at it.

Simply follow the instructions at and you’ll know exactly what to do.

Signing a Contributor Agreement

The last thing you may have to do, depending on what patch comes in, is to sign a contributor agreement (usually referred to as a CLA). This is a little piece of paper that assigns a license to your copyright in producing the patch you’re sending back to the hosting project (OpenWrap). You won’t always need it, and if you do, I’ll get in touch with you. Fear not, pull-request us as much as you can.

We are, after all, built by the community, and building for the community, in the open, from day one. That’s how we roll.