-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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.
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.
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.
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.
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.
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.
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.
No, we provide our own shell called o that provides the command environment from the command-line.
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?
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.
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.
The solution is rather simple. 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 delete the content of the wraps folder completely, and do an o update-wrap in your project, all packages will be re-downloaded.
On the bright side, 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.
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 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.