I googled this a lot and I found very poor solutions on how packages are managed in C++.
Let's suppose that I am working on a project called Project C which is dependent on C++ project Project B, and Project B is dependent on another C++ project Project A.
Currently, we use Visual Studio to develop our projects. When Project A changes, every single developer pulls the changes and recompiles the project locally. Every single developer has a lib folder with all of these dependencies that contains the DLLs and header files that we copy for each project manually.
Then since we know the dependencies, we then go to every project that is dependent on Project A, copy the dlls of Project A from lib folder and recompile those as well until we get what we want.
I know however, that C# has nuget and one can manage external dependencies and Java has maven where one can do the same.
What we currently do is a manual, error prone and extremely time consuming process. Is there a way to handle dependencies for C++? We should be able to build with the debug ddls of the dependencies when compiling as debug and the release dlls when compiling as release. For now we just need to have the latest dlls.
We have jenkins installed and if we could use that to help us that would be perfect. For java projects our java engineers compile the project and maven packages are pushed into a maven repository from where everybody else is just pooling. As simple as that. But how we can achieve similar functionality in C++?
Related
I've been redesigning my custom VC++ build to be compatible with the new TFS 2015 Build solution.
The issue is running msbuild. I can post perhaps a simplified version, but my solution contains two items:
1 Makefile Project designed to build all of the libraries required, and
1 .exe project.
I have a reference in the .exe project to the makefile project, so that the build of the .exe forces the build of the library if needed.
The issue we are seeing is that when we do a rebuild with msbuild of the solution, it first rebuilds the library, and then when it gets to the .exe, it cleans the library project, causing some of the rebuilt files to be deleted and then preventing the link of the .exe file because the .lib file was deleted.
Why is it cleaning the makefile project again? It seems like when it gets to the .exe project, it re-resolves the dependency, and does not know that the library project was already rebuilt.
Thanks in advance. Larry
If multiple projects are in the same folder, Visual Studio attempts to erase output folder (typically Debug or Release) when the next project will be compiled. The best solution is to put each project in the separate folder.
I didn't go through all details but the reason this happens is that when building on the command-line, rebuilding the exe project results in Clean + Build of the exe project, and the Clean target for the exe project eventually calls the CleanReferencedProjects Target which results in Clean being called on your Makefile project (and later on, Build as well).
This CleanReferencedProjects is conditional on the properties BuildingInsideVisualStudio and BuildProjectReferences, so building inside VS skips this step anyway because BuildingInsideVisualStudio is true, and it's even documented:
When building the project directly from the command-line, clean those referenced projects
that exist on disk. For IDE builds and command-line .SLN builds, the solution build manager
takes care of this.
The BuildProjectReferences property is documented as follows:
By default we will build (and if applicable, clean) all project references. But this can be used to disable that
So one possible solution is calling msbuild some.sln /t:Rebuild /p:BuildProjectReferences=False. In the case with only 2 projects this will work properly, but I cannot guarantee this will always work in more complicated situations with more inter-project dependencies.
Now one thing got me wondering: how come I've never seen this behaviour myself? The answer lies in that I don't use makefile projects often, and the C++ projects which I do use are slightly different: there, the Rebuid target is defined in terms of Clean+Build (while for a Makefile project it is a standalone, separate target). As such when the exe project calls BuildProjectReferences, it will call Clean in the C++ project, but that results in
Target "Clean" skipped. Previously built successfully.
because when the C++ project's Rebuild was called it called Clean and Build already.
So another possible solution is doing the same for the Makefile project. You say that your Rebuild has additional requirements; I don't know what they are nor why they are needed (and arguably it is wrong that Rebuild does not have the same effect as Clean + Build) but this might work anyway, for example with this in the makefile project (all the way at the end of the file):
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
<!--additional requirements here perhaps?-->
</Target>
everything beaves properly and Clean/Build is called once only.
If none of these solutions apply I don't immediately see another way than removing the makefile project from the solution, and manually building it before the solution both locally and in TFS.
I migrated a visual C++ solution containing 70+ projects to VS2013 Update 5 from VS2008 SP1. The VS2008 SP1 was using merge modules and in VS2013 I am using this plugin to achieve this functionality. However, the merge module is not detecting external dependencies of the dlls I am building. For example, one of the dll is dependent on ace.dll (and specifies ace.lib in linker->input) but that dependency is not detected. In VS2008, the same dependency was detected. Any idea what could be wrong or where to look for?
I'm surprised that it previously detected that dependency in the VS 2008 setup project. To my knowledge, there is no link between the VS 2008 development project that you might be using to build your code and the dependencies in the setup project.
a) You can drag and drop files from anywhere into your setup project. There's no requirement that a VS setup project generate an MSI file from the files in your VS 2008 project.
b) A dependency on a particular Dll cannot result in that Dll being included in the setup because a huge number of dependent Dlls are included in separate redistributables. These Dlls might even be in the prerequisites of the setup project and that's how they get installed. You don't want (for example) every Crystal Reports Dll, SQL Dll etc in your MSI setup because they are required to be installed via redistributables or their own merge modules. There is no grand database of every Dll and which redistributable or merge module should be used to deploy it, so VS projects certainly don't know.
c) Not all dependencies can be detected by looking at the binary file. COM dependencies are not listed anywhere in a binary because they're linked dynamically via guids, so they can never be detected that way.
In general the bad news is that the developer needs to know which dependencies need to be installed individually, which come in redist setups, and which are standad Dlls, such as those that are part of the OS and never need installing.
I'm working on a VS2012 solution. This solution has a C++ project as a main project. The main project references several external libraries, and I might add a couple of extra libraries as well in the future.
The solution also has a C++ unit test project to test the code. I have a reference in the unit test project to the main project.
However, unlike with C# or other CLR-type projects, this somehow doesn't mean that the references in that project are copied. (might be that in those projects a .dll reference is all that seems to be necessary to get the job done)
I'm currently unable to include files from the main project, nor are the libraries that the main project has included or which it is linking to included in the test project.
I'd like to know if there's a way to access all the main project's files, include search directories and library references without editing the unit test project's properties all the time. Is there a way to do that? I've tried setting Use Library Dependency Includes to true in the unit test project's settings, but it keeps getting reset to false.
Will enabling copy local or copy local sattelite assemblies help solve this?
Copying output of native project referred in other projects does not work like in .NET because the mechanisms are different. The one solution that comes to my mind now is adding a post-build event action to copy the output to the desired folder.
I am new to Visual Studio, and I am trying to figure out the best way to organize my projects.
I am writing an application using the sfml library, and I have various resources (images/sounds) that I am using. I dropped these into the project folder, and everything works fine when I launch my application from Visual Studio.
I am wondering though, how does this translate to when a program is deployed? If I go into my solution's debug folder, and try launching the exe, it is unable to locate any of the resource files. Am I suppose to tell Visual Studio to copy files to an appropriate directory, and if so how?
Thanks for any advice or links.
For slightly more complicated "deployment" scenario, you can use post-build scripts to copy the correct files into the output directory and even package it into a zip file, for example.
If you find yourself writing more than one page of batch you may want to consider the options below, because batch is a PITA to debug.
Recent MSVS project files are actually MSBuild files (just open the .vcxproj file in Notepad or Vim). For instance you can use the Copy task, invoke arbitrary programs using the Exec task, etc. It can be a bit more sophisticated than the batch script in post-build scripts. MSBuild 4 can use Property Functions making it quite expressive. Useful reference if you do this
For a "full blown" project, you'll want to roll a dedicated build system using a dedicated MSBuild file, NAnt or even higher level wrappers like Rake.
As a less popular alternative, in a previous project I built a small dedicated "builder" .exe project in the solution and have other projects depend on it. Then in the post-build scripts of the other projects I just invoke the builder projects with arguments to make it perform certain tasks. The advantage is that you can write C# (or F# or VB.NET) and not have to fight the build system (as much) and I think it works quite well for small-mid sized projects.
for my project, I direct everything into one directory.
Go to ur project configuration, change General->Output directory, General->intermediate directory, and Debugging->Working directory to one directory. The reason you cannot locate the resource files is because the debug directory is not the same as the output directory.
I'm trying to build a project with TeamCity Professional 6.5.2
I have a MVC Visual Studio 2010 project using a visual foxpro dll.
The build fails because the dll is not registered.
How can I register that dll in the build machine, as part of the build process?
Thanks!!
There are two different scenarios Rodrigo, your scenario will fall into one of these:
Assemblies which can be referenced by the project: Wherever possible, include dependent assemblies in your source control repository (the 10th Commandment), usually in a "libs" folder which is referenced by the necessary projects. This centralises all your dependencies, makes it easy for new developers to get started and solves your TeamCity build problem.
Assemblies which need GAC installation: There are times when the assembly simply has to be installed in the GAC (i.e. RightFax). Frankly, the easiest thing to do in this case is just to install the damn thing in the GAC. It's an exception and whilst some people will philosophically argue against it, alternatives can get a bit complex (i.e. automating installation as part of the build), and for money I'd rather invest the time elsewhere.
Installing assemblies on each machine (dev, build, prod) will make future updates and any continuous integration system difficult to maintain in the future.
It would be better to create a folder in your working directory (I call it "Resources") which contains a folder for each group of DLLs. Then you just reference the assembly directly from the Project each time. You get duplicate DLLs across different projects, but it keeps everything very clean and simple.
In Visual Studio 2010 you can download a little utility called NuGut which I believes helps to manage assemblies in a better way.
It is a bad idea to register all DLLs on build agent machine, sometime you can find out that you have to install Visual Studio on a build agent machine, for instance ;)
I would suggest to place such libraries along with your code base in Source Control system (I assume you are using it), and just reference lib's folder by declaring a MSBUild property like
<PropertyGroup>
<LibFolder>$(PathFromCommandLineOrJustHardCodedPath)</LibFolder>
</PropertyGroup>
And then before doing a Build/Compile just copy files from $(LibFolder) into the build $(OutputFolder) using standard MSBuild command Copy by specifying source and destination files, and thats it.
To force TeamCity to pickup Lib (dlls) files from VCS folder just add path mapping into the:
TeamCity Configuration Settings -> Edit Build Configuration -> VCS Root settings -> Client Mapping
EDIT:
In your case looks like you have integration test which depends on external COm Server which you need to launch, so you can programatically registr this DLL, for instance in TestSetup, and then do not forget to unregister it in test TearDown.
Anyway you have to just reference this DLL as
VS Project -> Add Existing Item -> Add as Link
+ set
Copy to Output Directory -> Copy if newer
How-To register COM dll: see this SO post
Finally I added a prebuild event in Visual Studio running the regsvr32 command. The dll was in a known location, so I referenced this way:
regsvr32 /s $(SolutionDir)Lib\ProjDataAccess\ProjDataAccess.dll
Agree with Troy Hunt.
For a Continuous Integration with TeamCity 8.0.2 where you need an assembly (custom made shared assembly) reference from GAC, do the following.
1. Add the assembly to the build pack (In my case its nuget package).
2. Before starting the build process (MSBuild, Visual Studio etc), register the assembly to GAC with the help of a command line build runner.
3. Continue with the build process.
By following the above steps, if you are using MSBuild, the build process can link to a valid reference from GAC, which can produce an expected build result.
In my case, where the code refers a custom component from GAC, MSBuild ignored the assembly reference and completed the build process without an exception. But the deployment with the build output failed. To overcome this situation, I've used the give steps.
Note: It is mandatory that the TeamCity agent needs to run under an elevated user account. Else the addition to GAC won't be permitted and the build process can fail.