Skip to content
eskitek edited this page Oct 31, 2012 · 17 revisions

Frequently Asked Questions

## General ### 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.

### I heard OpenWrap was locking you in and had to be distributed with my application. Is that true?

No, it's absolutely untrue, and whoever told you that is either uninformed or trying to spread fear, uncertainty and doubt. OpenWrap doesn't "lock you in", you're still free to add your own library references, or to use an alternative package manager for some of your dependencies. It doesn't require anything to be installed on your machine. What we do do is add the references when msbuild resolves them rather than store them in your csproj files, which means that the only "lock-in" that exists is that the msbuild target files we provide has to be checked-in alongside openwrap. Without this, we couldn't do things such as auto-download of packages, detection of what gets built and auto-package your projects.

As for distributing OpenWrap, absolutely no need to. If you just build your application, the result of your build will be the same as if you never had had OpenWrap anywhere, all your referenced assemblies will be in your output folder, and you can go and use the output in any way you wish. And if you look, no openwrap there. You can still use the Publish feature in Visual Studio. Nothing changes. Of course, if you do want the runtime dependency resolution, you have the option of using OpenWrap as any other library, but that choice is yours.

### 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.

### I also want to use packages from NuGet. What do I do? Check out the page on NuGet on this wiki ### Is there a user-interface?

A user-interface is already present, it's called the command-line. A graphical user-interface is being worked on. It will 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.

### 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.

### 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.

## Publishing Packages ### 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. There is a blog post on how to put any file into an OpenWrap package.

### I want to know more about package descriptors Check out this page here: Package-descriptor. It will give you details about how the package descriptor is constructed ### The build parameter in the descriptor file seems pretty important. What else should I know about it? When you have understood about the package descriptor and have more questions about the `build` parameter, check out this page: Building-packages ### What is package anchoring and why is it relevant? This page here explains in more detail package anchoring: Package-anchoring ## Issues ### 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.

### ReSharper shows some code as Red, even though OpenWrap is initialized correctly. What have I done wrong?

It's possible that your version of OpenWrap doesn't support your version of ReSharper. Have a look at the ReSharper integration section to confirm, and update OpenWrap to a newer version if necessary.

Also, if you have installed previous versions of OpenWrap it's possible that ReSharper cache can get out of sync and prevent proper initialization of the ReSharper / OpenWrap integration. To reinitialize those caches, close Visual Studio, delete the .cache files that live alongside the solution, as well as the resharper temporary directory. Note that the cache files may not be visible in the Windows Explorer, however a search for .cache will reveal them. Make sure you do not delete the _cache directory from openwrap.

### I updated OpenWrap and I get a _namespace not found_ or _name not found_ error, what can I do?

If you have an older version of an OpenWrap package in your system repository and a newer version in your project repository, or the other way around, sometimes commands stop working completely, and even get-help doesn't work anymore.

To force an update of the system repository, you can use the o -ShellPanic command which will automatically force an upgrade of OpenWrap in the system repository, putting you back to a known working configuration.

If you want to do it manually, delete the %LOCALAPPDATA%\openwrap\wraps folder and re-run the o shell, all the openwrap packages will be re-installed. If you want to keep your other packages, you can simply remove the files starting with openwrap, openfilesystem and sharpziplib, and the folders in %LOCALAPPDATA%\openwrap\wraps starting the same way.

If it's within your project, it's easier. Just issue the command o update-wrap -UseSystem command to use the system repository version of OpenWrap to update your project, potentially with the -ShellPanic input too if that version doesn't work.

Since the introduction of the 4xx series of OpenWrap, the problem should not happen again. And if it does, there's a feature coming up that should address it forever, the -force argument to update-wrap and add-wrap.

### 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.

### On Windows I renamed my solution directory, now Visual Studio complains it can't find OpenWrap.targets file OpenWrap uses a soft directory link to always point to the correct version of OpenWrap. This link becomes invalid when the path changes. To remedy this you can simply go in the folder in which your solution exists and do an `o update-wrap`, which will re-establish the soft link. Alternatively, to do it manually, do the following:
  • delete the openwrap directory that is inside your wraps directory
  • copy the path to the currently used openwrap installation in your project. This will be of the form wraps_cache\openwrap-1.0.0.nnnn . If there are several folders like that, take the one with the highest version number and copy the path.
  • Open a command prompt with administrative privileges
  • make sure you are in the wraps directory of your project and issue the following command: mklink /D openwrap path_that_you_copied

You should now have a working soft directory link again and Visual Studio will find the proper .targets file.