Building a distribution/installer with the help of OpenWrap

[Sergej Koščejev]

Another problem I'm now trying to solve (I hope I'm still within the
acceptable limit of the number of messages per unit of time ;-)): I
have built a couple of wraps, with dependencies, and now I want to
create a "distribution", i.e. a zip file or an installer, that
combines a couple of these packages plus their dependencies. What I
need is to get all the dependencies in some folder, and then I will
have a build script that will get the right things out of the
dependencies, put them in a certain directory structure, and create a
zip file out of the result.

Currently I'm trying to (ab)use anchored dependencies like the
following:

mybigprogram.wrapdesc:
depends: library1 anchored content
depends: library2 anchored content
depends: plugins1 anchored content
depends: plugins2 anchored content
... etc

This puts the libs and plugins in a fixed place under wraps. However,
if library1 depends on log4net non-anchored, log4net gets added as non-
anchored to mybigprogram as well, and my well-thought plan breaks
down.

This leads me to a question: shouldn't dependencies of anchored
dependencies be forcefully anchored as well? Though I see that for
OpenWrap itself they are not anchored and it works fine.

Or can OpenWrap help me with my task in some other way? I think I can
use openwrap/_cache in combination with wildcards to make the
packaging script work regardless of version numbers but I was hoping
for something a little bit cleaner. I'm coming back to .NET from the
Java world so I have become a bit religious and spoiled regarding
packaging/dependency handling.

Sergej

[Sebastien Lambla]

What is the reasoning to create another package from the aggregated content of other packages? If I understand the scenario better I could possibly understand what you are trying to achieve better.

Note that if you want a package that references a bunch of other packages, you can create a meta-package that contains only the dependencies (o init-wrap -meta), and make sure you setup use-project-repository: false to prevent the wrap folder from being needed. That way when someone pull your meta package, it pulls all its dependencies as well.

Seb

[Sergej Koščejev]

The reason is basically to create an installer (or a zip file)
bundling several projects together. Imagine that you have
VisualStudio-10.0.wrap and ReSharper-5.0.wrap, and want to create a
VisualStudioWithResharper-1.0.msi out of these, then run some
integration tests and if everything works fine, release it to
customers.

But maybe I'm approaching the problem from the wrong end. It now
occurred to me that OpenWrap is only meant to manage library versions
and assembly references, not final packages, so I'll think of a
different approach.

Sergej

2011/3/2 Sebastien Lambla <s...@serialseb.com>:

[Sebastien Lambla]

Well openwrap is there to manage dependencies, whatever they are. What is the end user expectation? Can you not simply rely on openwrap for your package rather than create another one?

In the case you describe, I'd just push the package to a package server and let consumers use that.

[Sergej Koščejev]

But .wrap is an opaque format, so how can an end-user use a .wrap
package? Ok, it's technically a .zip but I consider this an
implementation detail, otherwise it would have been named .zip, not
.wrap. And besides, openwrap seems to have its own idea about where
things are to be located in the .zip, and I don't mind as long as it's
used for libraries, but for my application I want a certain different
layout.

2011/3/2 Sebastien Lambla <s...@serialseb.com>:

[Sebastien Lambla]

Well, what I'm saying is I don't know what your scenario is so I don't understand what you require.

If it's an end application to package and deploy as an msi, with associated dlls, the result of the build of your application will be in the output folder (copied from the wraps) so you don't have to concern yourself with pulling stuff from the packages. If there's another scenario, I don't understand what it is, so I can't quite help you.

[Sergej Koščejev]

As I said, OpenWrap no longer seems to me to be the right solution
here, but I'll try to state the problem anyway.

I have an application, let's call it App, which supports plugins.
There are three components: App, SPI, and Plugins. App depends on SPI
and a lot of third-party libs, and produces an .exe file (plus
.config). Plugins depend on SPI and produce a couple of .dlls. SPI
depends on a couple of third-party libs and is a single .dll.

What I need to create is a Distribution.zip containing
App+Plugins+dependencies. Note that there is no direct dependency
between App and Plugins so I can't really use the "copy everything to
output" mechanism of MSBuild directly. I would have to invent some
project that depends on App and Plugins but it feels a bit weird,
especially since that project would depend on App which is an .exe.

A better solution (that I'm currently thinking of implementing) would
be to have App produce a .zip of App.exe+dependencies (including
SPI.dll) and have it uploaded to some kind of repository, then have
Plugins produce a .zip of Plugin.dlls and have it also uploaded, and
then have some build script to get the latest versions of App.zip and
Plugins.zip from the repository, create a package, run tests, release,
and so on.

2011/3/2 Sebastien Lambla <s...@serialseb.com>:

[Sebastien Lambla]

You know, that's what we do with OpenWrap as the plugin discovery mechanism. The app is a composite mesh of all the plugins, which happen to be deployed openwrap packages themselves. Then we simply use the mechanism in OpenWrap to read the packages we ship and load the correct DLLs.

Any reason why you do not want to use openwrap as your plugin discovery rather than roll your own?

[Sergej Koščejev]

Um, what plugin discovery mechanism? OpenWrap has one? I think I
missed this, is this covered anywhere?

[Sebastien Lambla]

OpenWrap is a plugin architecture. For a set of dependencies we can load up the correct assemblies through the IPackageManager API. You can see what it looks like in the code of the commanding system, as it's all plugin based too.