Re-compile EE binaries against Phone references - #678
Conversation
Even though they share the same APIs, the desktop and phone versions of the Concord binaries have different strong names. In order to support both scenarios, we have to produce each of our EE (product) binaries twice: once referencing the desktop assemblies and again referencing the phone assemblies. Catch 1: There are no reference assemblies for the phone versions of the Concord binaries, so we explicitly re-assemble the same reference IL with a different strong name key. Catch 2: We can't put two copies of each assembly in a single output directory, so we reuse the existing Phone subdirectory and put both the new references and the new outputs in there. We do not run our tests against these assemblies since they differ only in strong name (references).
There was a problem hiding this comment.
Since you're including the project after the GUID is set, the other project will overwrite this.
There was a problem hiding this comment.
I'd be curious to know what shows up in the .sln file (whether VS cracks the project and reads this directly or uses the evaluated property from MSBuild). If it's the former, it might not matter that this is overwritten. If the latter, then yeah, we need a new property group below the Import...
There was a problem hiding this comment.
Actually, the Roslyn.sln changes are below...I could have just looked... :)
It seems like the sln file gets the ProjectGuid directly from the project file, so the overwriting shouldn't have any negative consequence.
|
FYI @pnelsonmsft |
There was a problem hiding this comment.
Should this be $(OutDir)Phone%(Identity).dll?
|
As privately discussed, there's a few problems with this: by having projects that other projects, the VS IDE won't properly reload projects and their contents. Either an approach with separate configurations or shared asset projects would mitigate those concerns. |
|
As @jasonmalinowski mentioned above, we discussed a new approach offline, so you might want to hold off until I've posted a new iteration. |
|
We're going to try to straighten out the strong-name signing of our references instead. |
…d50345efcc5c Localized file check-in by OneLocBuild Task: Build definition ID 10077: Build ID 6347393
5 participants
Even though they share the same APIs, the desktop and phone versions of
the Concord binaries have different strong names. In order to support
both scenarios, we have to produce each of our EE (product) binaries
twice: once referencing the desktop assemblies and again referencing the
phone assemblies.
Catch 1: There are no reference assemblies for the phone versions of the
Concord binaries, so we explicitly re-assemble the same reference IL with
a different strong name key.
Catch 2: We can't put two copies of each assembly in a single output
directory, so we reuse the existing Phone subdirectory and put both the
new references and the new outputs in there. We do not run our tests
against these assemblies since they differ only in strong name
(references).