可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I have 3 solutions and solution A requires built versions of the dlls from solution B and C in order to compile. it is not possible to merge it to one solution...
So far it seems that Visual Studio doesnt support solution references and msbuild is clever enough to know that you are building one solution from another etc if I try that way. The overall goal is to try to make the multiple solutions seem almost like there is only one - just solution A.
I believe this is a common problem, but how do you link it up nicely?
回答1:
This question has popped up in different, but related, forms. There is actually an MSDN page that covers this.
What you're looking for is a multi-solution approach akin to the Partitioned Single Solution Model for Larger Systems. Have one "everything" solution that builds everything and maintains your inter-component dependencies. This is what you build when you need to build solution A. You then have separate solutions that only include components B or C. Essentially, you'll still have 3 solutions, but you'll add the projects from solutions B and C into solution A.
回答2:
I have recently discovered that in Visual Studio 2008 you can include existing projects in multiple solutions. The only downside so far seems to be that if you make a change to a shared project and have multiple solutions open that use that shared project you will be asked to "reload" the other solutions.
So, just "Add Existing Project" to all the solutions that need the project. I am using TFS on my current site and there seems to be no issues with source control ether.
回答3:
It should be project level you are looking at I believe. Build the projects contained within Solution B and C and then add references to the DLLs in the relevant projects in Solution A.
In Msbuild if you have a property group
<PropertyGroup>
<SolutionsToBuild>SolutionB</SolutionsToBuild>
<SolutionsToBuild>SolutionC</SolutionsToBuild>
<SolutionsToBuild>SolutionA</SolutionsToBuild>
</PropertyGroup>
Then execute the MSBuild Task
<MSBuild Projects="@(SolutionsToBuild)"/>
Hope this helps
回答4:
You can try to automate the merge process to save some time:
http://code.google.com/p/merge-solutions/
Although we had slightly different problem: about 15 solutions (~150 projects in total) that were using one common library. The problem was that if we tried to merge all of them into one in order to refactor / exterminate redundant code from common library.
1. merging 15 solutions involves a lot of clicking and waiting in VS
2. resulted solution was never up to date - nobody bothered updating it because of its size
回答5:
You could try to add command line build commands for the dll (in solution B and C) you depend on in the prebuild events of your projects (in solution A)
回答6:
If you can't put projects B and C into the same solution as project A then there's no way to make sure you have binaries for B and C containing the latest source code when you build project A.
The easiest solution I've seen is to have a common folder in the source code repository where every project copies its binaries if they need to be shared. Then all other projects can reference binaries in that folder as long as your local folders look the same as the repository.
Not a perfect solution, but it's pretty easy to work with.
回答7:
You can add a Makefile project to solution A which would build your solutions B and C (using msbuild for example) and make all the projects in A dependent on that Makefile project. This way you wouldn't be able to add project references to projects in B and C, but you can use dll references and they will always be built from latest sources.
回答8:
According to this answer, I would recommend you to create your own batch file which will build the relevant solutions for you.
That's very handy to use because the build process will output the build progression (Similar to Output window in Visual Studio) to the command promote for each and every build executes.
Furthermore, in a case that you need to build one solution before the other, you can write your own build order, for example:
- build solution B
- build solution C
- build solution A (which internally uses "solution B" and "solution C" built files)
I've quickly written script to clarify the build order mentioned above and support most of modern Visual Studio versions.
Regards.
回答9:
I fixed the issue by putting the script in the pre-build event command line and if project A is failed to build throw msg alert
ECHO "build A project"
set AppMsg ="%SystemRoot%\System32\msg.exe"
set AppMsg
if not "%ProgramFiles(x86)%" == "" (
if exist "%SystemRoot%\Sysnative\*" set AppMsg="%SystemRoot%\Sysnative\msg.exe"
)
set AppMsg
taskkill /f /im "%PROGRAMFILES(X86)%\MSBuild\14.0\Bin\msbuild" "$(SolutionPath)" /t:Project_A_Name /p:Configuration=Debug;TargetFrameworkVersion=v4.5 /p:Platform="Any CPU" /p:BuildProjectReferences=false /p:VSToolsPath="%PROGRAMFILES(X86)%\MSBuild\Microsoft\VisualStudio\v14.0" 2>nul 1>nul
echo ERRORLEVEL %ERRORLEVEL%
if ERRORLEVEL 1 (
ECHO "failed to build test project"
%AppMsg% * "failed to build test project"
)
exit 0