FAQ

• What's a dependency manager?

A dependency manager is a tool responsible for finding components your application may require to run. At build time, such a tool will help you find an open-source library or a vendor's component for your application. At run-time, a component-based application could use the same mechanism to locate the screens a user has access to.

Some dependency managers work on .net assemblies, most rely on grouping dependencies in one file, usually called a package. This is why most of the tools you'll hear about use the term package managers.

• What does OpenWrap depend on?

Unlike others in this space, we rely only on plain old vanilla .net 3.5, while still supporting any project you want to build, from .net 3.5 to .net 4 to Silverlight. We don't even need Visual Studio, so you're free to use whatever editor you prefer.

• What can a package contain?

Anything you want. The packaging format used in OpenWrap is dead-simple, it's a simple zip file. Each of those zip files can have as many folders as one wants, we call them exports.

Of course, assemblies are one type of export that is already fully-supported on OpenWrap. You can learn more about the assembly resolution on the Using .net assemblies page.

• Why use OpenWrap over [insert favourite tool here]

OpenWrap has been public since April, and the majority of features built into it come from real-life challenges encountered by a team of developers building composite apps, using OpenWrap day in and day out as part of their development process. As such, a lot of corner cases are covered already, and the system is stable enough to be used for many different applications.

• Is there a user-interface?

A user-interface is already present, it's called the command-line. A graphical user-interface however is being worked on, to provide you with a subset of the functionality you can get from the command-line. It is of lower importance because we believe that once you've started using the command-line, the UI will feel awkward and slow to use. We do work on it because we realize some users prefer that way to interact with the system.

• ReSharper complains about references not being found when I first open a solution.

This is a known issue, simply trigger a build and ReSharper will update itself automatically. This is a known issue with the ReSharper integration code and will be fixed at some point.

• How does OpenWrap inject assembly references, I can't find them in Visual Studio?

It's on purpose. To be able to update references in projects and build them efficiently, we import assembly references as part of the build itself. We believe your project is yours and shouldn't be changed continuously every time we need to update something. OpenWrap is injected in the build process using a traditional @@, and adds its own references when the @AssemblyResolve@ task runs.

• Is OpenWrap only for development-time?

OpenWrap keeps both a project and a system repository. The project repository exists so that the exact dependencies you added at development time can be shared with anyone pulling the code from source control.

The system repository however lives both as a cache of existing packages and as a system-wide repository of packages and commands you can use from anywhere in your system.

Whenever you execute a command outside of an OpenWrap project, the commands come from your system repository, situated in %LOCALAPPDATA%\openwrap.

• Why do I get errors when building wraps for projects that contain a post-build event?

This is probably due to your post-build event containing a reference to $SolutionDir (or some other $Solution... macro). OpenWrap doesn't build using the solution file, so these are not available when building with OpenWrap.

• Do I need to restart anything when I update packages?

The short answer is no, you have nothing to do. Visual Studio will see the new assemblies next time you build, and ReSharper will get notified in real-time. And even if you update openwrap itself from the command-line, you still don't have anything to do.

There is however one exception. If you update openwrap used by a running instance of Visual Studio, you will probably get an error telling you that a package could not be anchored. Visual Studio keeps a lock on all files being used by its MSBuild process, which prevents the package anchor to be updated, preventing the new version of OpenWrap from being updated.

Sadly, even upon closing the solution, VS keeps the locks. The only solution is then to restart Visual Studio. You will encounter this issue with any package that contains MSBuild tasks you import.

• Is Powershell required?

No, we provide our own shell called o that provides the command environment from the command-line.