I have the following (simplified) solution structure:
ProjectA
|- Content: myexe.exe with CopyIfNewer
ProjectB
|- ProjRef: ProjectA
ProjectC
|- ProjRef: ProjectB
When I run a build of ProjectC where ProjectA is built also (e.g., because ProjectA is not up-to-date, or because I clicked "Rebuild all") then myexe.exe is put into ProjectC's bin output folder. However, in any other case, myexe.exe is NOT in ProjectC's bin output folder.
Is this a known problem? Am I doing something wrong? How to fix this?
However, in any other case, myexe.exe is NOT in ProjectC's bin output
folder.
Is this a known problem? Am I doing something wrong? How to fix this?
Test
First, l guess that the first project is a ,net framework project or even the three projects are based on the framework. In my side, l created such three projects and cited the relationships you mentioned for the three projects.Exactly, when I modified the codes of Project C(A and B already built before), the file cannot copy into Project C as you wish. But when l just have two projects A,B(B project reference:A), it always copy the files of the first project A into B(whenever l choose Copy always or Copy if newer or build or rebuild the project B). Besides,I tested three projects which are based on Net Core or .Net Standard works without problems.
Conclusion
So the reason for this problem is pointed out that the intermediate project, project B, is not built（up-to-date Skips the build ), so the files of Project A could not be copied to the Project C as the transit station. (especially for non-sdk framework projects). l think it is a feature or issue in Project Reference in Visual Studio. or you could report it to DC Forum for a detailed explanation.
Solution
You can add such property to the csproj file of project B to break the latest check and ensure that it is always built. You can add this node under PropertyGroup both in Debug or Release
<DisableFastUpToDateCheck> true </DisableFastUpToDateCheck>
Hope it could help you.
Related
To prevent circular dependency, i had to make a reference from (lets say) project A, to B's bin folder. When i run a rebuild or build in Visual Studio it creates bin folder and required dll references by A, under B project.
But msbuild command does not work that way. It does not create bin and dlls under B. I investigate the problem, found some solutions like using dummy class user method to make msbuild copy references under bin. But it did not work too.
Project A -> Project B/bin/C Dlls ->Project C
Project C Dlls required by Project A.
What do i have to do to make msbuild command create bin folder under B project?
It looks like the circular dependency is still present. It has only been circumvented by going directly to the bin folder. This bypasses the safeguards that call out a circular dependency at build time.
As a general rule, if you need to go directly to the bin folder then there's a problem.
I suggest refactoring the projects to remove the circular dependency.
I have a repository that contains two solutions. One solution (in this case solution A) for a web project that has a reference to a project in the second solution (in this case solution B) (in the same repository).
When I build the web project in VSTS I pull the repository, build solution B, and then build solution B.
Build solution B work, but, the build of solution A is failed cause the reference dll of the project in solution B didn't found
You have a few options:
1) Use project references. You don't need to depend on an assembly.
2) Use NuGet packages -- the shared piece is built via a CI process, turned into a NuGet package, and then published to a Packages feed. The dependent projects can reference the NuGet package and restore an appropriate version on build.
Which approach you should take depends on a lot of factors. If you're not worried about versioning, just use project references.
As Daniel said that it’s better to use NuGet packages.
Regarding reference the assembly file directly, refer to these steps:
Open your web project file through Notepad
Find the related reference and check Hintpath value, should be relative path.
Add Copy files task to your build definition (Before build solution A task) to copy corresponding assembly files to corresponding folder (per to that relative path)
I added into Solution(contains 30projects) Wix Installer, which is supposed to pack web service folder. Among files i want to pack is BIN file with plenty of dlls. On local with Release mode it works fine, however if i run TFS 2013 build definition over solution i get these:
C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\filesToBeInstalled.wxs (97):
The system cannot find the file 'C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\..\..\..\ABC WS\bin\ABC.Components.DataAccess.Lib.Utils.dll'.
I asked my colleage who administrate server and he told me that BIN folder isn't created in 'expected' location.
Now i don't have access to server and colleage is unreacheable, is here rule where binaries for all project/within solution are stored?
Update:
Somehow we overlook BIN folder - 'as configured' is and was set in definition however files still couldn't be found - problem was in build order(weirdly in VS2010 was correct) setting dependency wix project on target project helped - problem was that wix project was builded before target one.
Team Build creates uses a MsBuild parameter to redirect the build output of projects. If you need your Wix Installer to package up content that has been redirected, your installer script must be aware of this redirection happening.
The output structure of team build looks like
Build Agent Root
+- Unique build folder
+- src <- This is where your Wix project is placed
+- bin <- This is where Team Build redirects the project outputs to.
+- Test <- This is where Test Results are stored
This allows Team Build to figure out which outputs to copy to the drop location with a lot more accuracy, but it breaks any scripts that have hardcoded (or relative) paths to build outputs.
There is hope though, you can use the $(OutDir) or $(OutputPath) parameter to find the location Team Build has been configured to drop your binaries. You can use the '$(BuildingInsideVisualStudio)'=='' and/or '$(TeamBuildConstants)'=='' to detect whether your Wix Script runs in Visual Studio or in Team Build.
That way you can define multiple source locations for your Wix packages or to set the base directory to a certain value and use that variable in your wix scripts.
Or if you simply want your team build to match your bin structure when running in visual studio, set the 'output location' parameter in your build definition to 'as configured' - see this link for details:
http://blog.stangroome.com/2014/02/10/override-the-tfs-team-build-outdir-property-in-tfs-2013/
I have a solution that contains two projects:
- projectA has a nuget reference to ServiceStack ormlite
- projectB has a reference to projectA
When I build the solution the outdir for projectA contains all the assembly coming from nuget packages (4 assemblies), whereas the projectB only copies 2 of them. Obviously when I start it I get an FileNotFoundException.
I have already tried with no success to add private=true flag
I have seen many references to this problem and it gets very confused now about what is going on here (it seems that msbuild does not handle reference the way I think is the only thing I know:().
Any idea what could be done to have a reliable process to build my solution ?
The build will only copy to projectB's output folder the assemblies that are actually used by projectA and result in references in projectA's output assembly, regardless of which assemblies projectA references.
You can open projectA's assembly with Reflector or ildasm and see that of those 4 assemblies only 2 are actually used and referenced.
If the assemblies need to be there at runtime for projectB, add a reference to the NuGet package to projectB as well, or make sure they are copied. This post shows a general-purpose solution, but I haven't tried it.
Following Situation:
2 Team Projects
Dvelop of Team Project A added Project References of Team Project B to their projects.
For speeding up the Build I want to replace the project references with referencing the dll's directly.
My Idea:
in the csproj of Team Project A:
<ProjectReference Condition="'$(IsDesktopBuild)' == 'true'" Include="[Project Reference] >...
in the TFSBuild.proj
<AdditionalReferencePath Include="[buildoutputOfTeamProjectB]" />
OR
Disable SolutionToBuild and use the csproj files directly.
Thanks for your suggestions.
I would suggest that each project have a dependencies folder that contains the appropriate dlls that are required for each project. When a project that is depended upon is built it would be up to you to automatically update the dll in the dependencies folder or not via your build process (cruise control/nant/msbuild?). However, I would also give some consideration around deploying versions of the depended upon dll just in case you blow up the dependent projects usage of that dll. It would suck for someone to update their project (the depended on project), kick off a build, deploy their build output to the dependent project) only to break the project that relies on their code base. That sounds like a fragile way of managing dependencies.