I have a C++ solution built in MS Visual studio 2010 and it contains 2 projects. I would consider 1 out of it as my main project and it needs to get some output generated by the other project and then process it. Is there a way to do that in C++ ? I mean, to build a project through C++ code in some other project ?
I am not able to visualize your problem accurately, so pardon me.
As far as dependency between projects, you can try to use Makefile to manage the file dependencies.
Or try to combine both projects and use function accordingly to pass parameters and return output.
Please make use of referencing the second project library in the main project and make use of Methods to exchange the data.
Related
I am trying to build a project from the following Source Code (it accompanies a book I am currently reading). Unfortunately, visual studio can not run a library with the name "cyclone_d.lib". I believe this is because visual studio simply can not locate the file. I have spent several hours trying to fix this problem by changing the settings in the linker and project, for example adding Additional Directories, but I have not been able to get any results.
Please let me know how I can fix this problem and compile the code.
Thank You!
Your link to source points only to some Unix-style source files but no VS project files. So I can only guess and give general help.
A VS solution contains one or more projects. Each project has a build target, in most cases a EXE, DLL, or static library LIB. When you have a solution that includes an project with an EXE build target set the option "Set as StartUp Project" at that project in the solution tree.
If you don't have an EXE change your project setup to create a Win32 executable instead a library. For this task the most simple approach is creating a new project (Win32 Console Application or Win32 Project) and add all the source files.
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.
Currently i am using makefile to build the project but i want to convert it into visual studio 2010 project? After some research i can not find a single tutorial or guide to do this. Can any one help me by pointing to any of the relevant resource or step by step guide for it.
P.S: I have only elementary knowledge of makefile
I'd suggest to use CMake for creating VS projects. You just define your project structure, i.e. sources, headers, resources and CMake creates appropriate project/solution files for your target IDE: makefiles, Visual Studio etc.
After installation CMake provides a GUI, where you can choose your target IDE.
I know, this is not a direct answer to your question, but it is a way to make your projects more portable.
Is it possible to tell VS not to recompile some projects every time and use already compiled dll-s instead?
You can exclude any project from building in Configuration manager. Just unselect desired projects in Build column. You still will be able to debug those projects.
Instead of project references, you can add the compiled DLLs as references.
Any such referenced project will not rebuild if not changed.
However, since the references will now be to DLLs, you need some strategy to keep them synchronized and up to date with your code.
As I understood your question, you have a solution with multiple projects and you seem to have dependency of some of them on some other.
VS will always compile all the "loaded" projects. But when you add a reference to a project, add it directly to a (preferred) DLL assembly file, and not to one of the projects. This way the other project will be compiled but you are referencing the same DLL assembly over and over. Since if you reference the project, the output of the project is always what you reference actually.
Is it possible to make a solution in VS depend on (i.e. include) an entire other solution? I've seen some stuff about "Solution Folders", but these don't seem to be the same thing....? Thanks! (BTW, I'm using VS 2008)
Not really. You'd have to do one of the following:
Make a build script that builds the solutions in the correct order.
Pre-build solution A, and only reference the built binary outputs from it in solution B.
Make a third solution containing all of the projects from both solutions.
The first two items are the most common, where I personally prefer the second.
This post is old, but these days you can easily reuse dependencies in other solutions by building nuget packages for all of them. VS 2015 has nuget package building built in but is currently a Release Candidate. In Visual Studio 2013 you can use the Nuget.Packaging nuget package to allow your project to build as a Nuget Package.
Then you can just publish new versions of your packages to a local network share and configure it as a Repository in Visual Studio.
Then your other solution's projects can depend on that package.
For example, say you have a reusable Utility DLL in a Solution Called "Core Framework" and you want to use a utility in there on a WebSite you are building in a solution called "XYZEcosystem".
In the CoreFramework solution you would build a nuget package for the Utility Project that compiles to the utility dll and include the dll and it's pdb file in the package.
Then you publish that to your network share.
So let's say your package has an ID like "XYZ.Core.Utilities" with a version of 1.0.0.0.
Now in XYZEcosystem you would use the package manager console, set the repository drop down to your repository and type "Install-Package XYZ.Core.Utilities" and it will install the latest version of XYZ.Core.Utilities.
If you make a change to XYZ.Core.Utilities you can run Update-Package XYZ.Core.Utilities on XYZEcosystem and it will pick up the new version.
Take a look here: https://learn.microsoft.com/en-us/archive/blogs/habibh/walkthrough-adding-an-existing-visual-studio-solution-to-another-solution
Actually the method described adds all projects from another solution to the current solution, not quite what we want, but at least this saves time adding all of the projects manually one by one.
A solution is a collection of assemblies that build to create some kind of executable or dll. Having one solution depend on another does not make sense. The output assembly (executable/dll) depends on the assemblies that it references. If your solution depends on other assemblies, then reference them. You can add projects to your solution (File>Add>Existing Project) and then you can add refences these projects from your output project.
You cannot do that. And why would you want to?
Simply add all the projects that you depend on (the projects in the 'other' solution) to the solution.
Then use project references (not file references) between the projects.