I need to add some references to another project or dll just before the build process in Visual Studio 2015 starts and then I need to remove the reference after build.
Is it possible and what is the best approach for this?
Can I also add shared projects?
Related
I have a solution with a large number of solution level build configurations. Whenever I add a project to this solution, Visual stuido changes all of my configurations to build the new project. Is there a way to stop VS from doing this, or am I stuck reconstructing all my build configurations every time I add a new project to the solution?
I don't know of any solution within visual studio but you could do it by hand rather easily. Project files are simply xml files and solution files are text-based as well (and rather simple structured).
If you know how to handle MSBuild files (i.e. project files) you can even simplify them if you have many configurations.
This is the msdn article for MSBuild:
https://msdn.microsoft.com/en-us/library/wea2sca5(v=vs.90).aspx
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
We have a Visual Studio 2010 solution that has over 120 projects that reference each other in some way. All inter-project references are project references and not file references which helps Visual Studio determine the project build order automagically.
Out of 120, we have a few core projects that are not interdependant on each other and these projects are referenced by the rest extensively. Hence these projects are at the top of the project build order. These core projects have references from the .NET framework, Enterprise Library (and some of them have third party dll file references like a zip utility).
I cannot figure out why these core projects are ordered in a specific way.
What is the algorithm for the project build order for non-interdependant projects?
PS: I do understand I can influence this order by creating a fake dependancy using the Dependencies tab of Project Dependencies.
I believe that Visual Studio builds these projects in the order they appears in solution. If you need to adjust the build order of projects you can use Project Dependencies (do not confuse with .NET References). When you add .NET reference from one .NET project to another inside you Visual Studio solution the Visual Studio automatically creates project dependency. To modify project dependencies manually do the following:
Right-click on the solution in Solution Explorer.
Select Project Dependencies
From the drop-down list select project you want to add dependencies to.
Select dependencies for this project.
Also you can view the resulting build order by switching to the tab Build Order.
We are finally getting a source control system in place at work and I've been in charge of setting it up. I've read that it's usually good practice to not include binaries in source control so I haven't. However, we have two all-purpose utility projects (each in their own solution) that generate utility .dll's which are included in almost all of our other projects (all each in their own separate solutions). We add references to the utility dll from our projects.
I would like to have our solutions set up in such a way that if the reference dll isn't built, the solution will build the dll for itself, much in the same way a make file checks for its dependencies and builds them when they're out of date or missing.
I'm new to build processes with VS so try to keep the answers simple. Any links to general build process overview tutorials would be great too. Googleing for VS references returns a bunch of how-to add references links which is not exactly what I want.
Answer: (3 step process) Add a project reference, not a binary reference by right clicking on the solution, and adding an existing project. Then under the project tab, select project dependencies and modify the project so that one project depends on another. Finally, delete any old reference to the binary and re-add the reference using the project tab in the Add references dialog box.
Where I work we typically have project references rather than binary references (as we used to a while ago). When you include a project reference, the dll will build along with the rest of your app.
The only time we go back to binary references is when we are in between Visual Studio releases (e.g. 1 project is in 2010 and everything else is in 2008. The 2010 project will have to use a binary reference for a couple of months until everyone else catches up... Project incompatibility seems to be a Visual Studio limitation that shouldn't exist).
EDIT
To add a project reference right click the solution and click Add and finally "Existing Project." Make sure that the utility projects are also under source control, and make sure that the workspaces are set up correctly or other people will not be able to open up the projects correctly!
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.