Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource and Contracts dlls not correctly added in wrap #335

Open
rvdginste opened this issue Jun 16, 2012 · 1 comment
Open

Resource and Contracts dlls not correctly added in wrap #335

rvdginste opened this issue Jun 16, 2012 · 1 comment

Comments

@rvdginste
Copy link

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
Copy link
Author

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

rvdginste added a commit to rvdginste/openwrap that referenced this issue Jul 30, 2012
rvdginste added a commit to rvdginste/openwrap that referenced this issue Jul 30, 2012
rvdginste added a commit to rvdginste/openwrap that referenced this issue Jul 30, 2012
simonlaroche pushed a commit to simonlaroche/openwrap that referenced this issue Feb 27, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant