We have a TFS C# Collection with projects like this:
OurCollection
OurControls
OurDBFuntions
OurCommonCode
Project1
Project2
Building Project1 or Project2 requires builds of all the "Our" projects. TFS will not let me create a build definition in the OurCollection space - it requires me to be in one of the Project spaces. But I can't load from the repository to get all the "Our" stuff so that Project1 or Project2 can compile, link, and complete.
The Configuration has links to all the "Our" projects and requires them to build before building the Project1 or Project2, but the sln and all other source files are not downloaded from the repository and the pathing is limited to subfolders of $/Project1.
Can I accomplish what I need to do?
Thanks,
Tony
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
We have several projects - the "Our. . ." projects, which build as DLLs, linked as references. Each "Our. . ." project has its own solution and needs to be built before our Project1 is built. The Configuration Manager has them marked to build and we have a build order. When I create a build definition, it lets me point to a solution in the Project1 folder - which works so far. But it doesn't download from source control for the other projects. So the specified configuration can't find the "Our. . ." solutions and then the Project1 build can't find the references and everything fails.
I basically need to have the folder set to the collection level so I can get all the projects from source control rather than just Project1.
I'm not sure what the "Shared Projects" feature is and don't find a reference in any of the documentation on how to set up a build definition.
Thanks,
Tony
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm trying to create a new TFS 2015 build definition . . . and to make it clear, here's my hierarchy
OurCollection
Team Project OurControls
Team Project OurDBFunctions
Team Project OurCommonCode
Team Project Project1
ProjectGUI
ProjectRules
ProjectDBAccess
Team Project Project2
One of my problems is that, in the build definition, when I go to Source Settings and try and add a referenced solution path, it will only add a path that is below the TEAM Project1 level. I can't go back and add a path to a different Team Project in the OurCollection. It will only allow me to add a referenced solution path that is below the Team Project Project1 path in the hierarchy.
So if I move the Team Project OurControls solution under TEAM Project Project1, now I can add it. But TEAM Project Project2 can't.
Several other post seem to indicate getting build definitions set at the collection level. When I try that, it won't let me - I have to pick a TEAM project. Once I pick a TEAM project, I'm stuck in that tree.
So maybe the question is - how do I create build definitions at the collection level? When I go to server:8080/TFS/OurCollection, I do not get a Build Tab. I have to go to server:8080/TFS/OurCollection/Project1 to get a Build tab.
Thanks for any help,
Tony
You can try to use the following folder structure
C#Collection
OurCollection (project)
OurControls (project)
OurDBFuntions (project)
OurCommonCode (project)
Solution1 (sln including project1)
Solution2 (sln including project1)
The 'our projects' can shared across multiple Visual Studio solutions. They don't need to added to the solutions, you can using the 'Shared Projects' feature, just adding them by doing 'Add existing project'. Then you can create one definition for solution1 and build the project1 sucessful by selecting the soulution1.
Soulution1
OurCollection (project)
OurControls (project)
OurDBFuntions (project)
OurCommonCode (project)
project1
Related
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.
I have a project which is still being developed.
I want to make unit tests in another project but i couldn't manage to use the existing source files.
Say that, i have header1 and source1 in actual project. I want to include hedaer1, source1 and testSource1 files in the test project. And whenever i update the code in header1 or source1 in the actual project, it must be updated automatically in the test project.
I can include the headers in test project, but can not compile. Seems like i have to link static or dinamically in the test project. Is there any solution ? By the way, i'm using Boost test framework, if it matters.
I had the same problem with GTest framework (but I think it does not matter). So I found 2 possible solutions:
Change output type of the tested project.
Make tested project output as "static library" ( Project - Properties - Configuration Properties - Configuration Type - Static Library (.lib) ), then add the library file to the testing project (Project - Properties - Linker - Input - Additional Dependencies - Path to lib file from tested project)
there is article to read http://leefrancis.org/2010/11/17/google-test-gtest-setup-with-microsoft-visual-studio-2008-c/
OR
Add files from tested project to testing project through menu Project - Add Existing Item (choose *.h and *.cpp files you need).
If someone has more convenient solution to the problem it would be great to know it.
Project A references Projects B. Project B references Project C. Project A does not reference Project C.
This builds fine locally. However, on the build server it errors out because Project A does not reference Project C.
Error:
error BC30009: Reference required to assembly 'ProjectC, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' containing the implemented interface 'ProjectC.IFoo'. Add one to your project.
How can I catch this before committing?
Edit:
Here's more info on my issue: http://sstjean.blogspot.com/2006/11/msbuild-cant-find-secondary-references.html
Here are two things you can do as a best practice to ensure your projects are referenced correctly and MSBuild will be able to find your referenced projects correctly.
Use project references instead of referencing dll's. Create a folder called dependencies or libs and place any referenced dll's within this folder.
Check the build order and project dependencies tab for each project by right clicking project and selecting project build order. Ensure that every reference in your project is being built by that project.
MSBuild does not know what a .sln file is. MSBuild reads and parses the .sln file to determine the build order of projects. By having project references MSBuild will be able to traverse and build the projects in the correct order. See below link for more information.
This link also helps explain why you would see different behavior and how to catch it.
Visual Studio Integration (MSBuild)
Within Visual Studio, the solution file and project build ordering are controlled by Visual Studio itself. When building a solution with msbuild.exe on the command line, MSBuild parses the solution file and orders the project builds. In both cases the projects are built individually in dependency order, and project to project references are not traversed. In contrast, when individual projects are built with msbuild.exe, project to project references are traversed.
When building inside Visual Studio, the property $(BuildingInsideVisualStudio) is set to true. This can be used in your project or .targets files to cause the build to behave differently.
Go to your project references and right click Oracle.DataAccess then go to properties and in properties page make sure that specific version is false and copy to local is set to true.
I am trying to add a dependent project in XCode 4. The link to the project is this: https://github.com/jverkoey/ObjQREncoder
The author described a way to add this but it's for XCode 3. I am trying to add it to XCode 4.
I dragged the project inmy frameworks, then went to Targets and QREncoder in Target Dependencies. Then I added libQREncoder.a in "Link Binary with Libraries". Then I added this for header search path "src/Classes".
When I include "QREncoder/QREncoder.h", it gives me this error: file://somePath/FINALQRAppDelegate.m: error: Lexical or Preprocessor Issue: 'QREncoder/QREncoder.h' file not found
This is how my project is set up:
FINALQR is my project to which I am trying to add the dependency and the dependency project is in src.
Thanks.
The problem is it doesn't recognize the QREncoder class.
Only Xcode 4 workspaces benefit from shared build folders across multiple projects. From the main menu, select File > New > New Workspace... Save the workspace, then drag your subprojects into its Project navigator panel.
Be careful where you place them (make sure you're not making one project a subproject of another within the workspace) so that they're all top-level projects within your workspace. This will cause them to share the build folder and automatic dependency detection should work.
Unless, of course, you have custom search paths set in your targets' build settings. :-)
I think your problem is you need to set the following as your search path:
"$(SRCROOT)/src/Classes"
not
"src/Classes"
If you already have an Xcode4 project, you should be able to drag QREncoder into it as a subproject, as I think you have already done, and then add the .a file, also as you've done.
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.