OpenWrap / openwrap

The OpenWrap repository
171 stars 37 forks source link

Resource and Contracts dlls not correctly added in wrap #335

Open rvdginste opened 12 years ago

rvdginste commented 12 years ago

Using latest master of OpenWrap, the generated code contracts and resource dlls are not correctly added in the built wrap.

The code contracts dll is not picked up at all. The dll sits in the CodeContracts folder in the binary output path after the build.

As for the resource dlls, one resource dll is picked up and it put in the binary root of the wrap (bin-net35). The project actually contains 2 resource dlls, in sub folders "fr" and "nl" in the binary output path; both should be copied and placed in their respective folders inside the bin-net35 folder in the generated package.

rvdginste commented 12 years ago

I checked the code to see how this is currently done. I noticed that the MSBuild code nowadays adds everything that it generates into the "_OpenWrap-CurrentBuildOutput" variable, which is then filtered to eliminate everything that it already knows into the "_OpenWrap-FilteredBuildOutput" variable. This is then passed to the "BuildOutputFiles" property of the PublishPackageContent task.

This part correctly handles the satellite assemblies, but still misses the code for Microsoft Code Contracts reference assemblies. I'll see if I can add that.

But then further on, in the implementation of BuildWrapCommand (line 273), in the GeneratePackageContent method, the RelativePath property is always set to "fileDescriptor.ExportName". This is wrong I think, because at that place, the relative path of the file is lost, and this is important for both the satellite assemblies as the contracts reference assemblies. Either that, or either the generated "[built..]" commands are wrong.

I think this should be fixed by somehow specifying for each binary output file which is the corresponding "root", so that instead of only having one full path, you get a pair consisting of a "root" path and a relative path within that root path. I think this is needed because some binary outputs are given as a path within the defined "$(OutputPath)", and others are given as a path within the defined "$(IntermediateOutputPath)". When collecting the binary outputs inside the MSBuild code, one actually knows which root path it is. The combination of the root path and the relative path is then enough to both locate the file, and place it in a proper spot inside e.g. "bin-net35".