I've worked with SourceGear Vault for sometime for source control but I've run into a problem - which is going to be all the more common.
I have a visual studio solutions that looks like so:
-Main solution
- Web App Project
- Shared Class Library 1
- Shared Class Library 2
The problem is that I can only bind the solution to one repository, however the class libraries are shared, they need to be used by multiple solutions.
Is there a source control solution that anyone knows of that will allow for a solution to contain multiple projects, all bound to different repositories?
Thanks in advance
Al
Build the shared libraries separately and reference the assemblies. The building of the libraries can be automated (e.g. using Continuous Integration), so that this is an easy and efficient solution.
A solution may be using SubVersion and the svn-externals.
You can integrate it in Visual Studio via VisualSVN plugin (you must purchase it).
If you want purchase it, you can use TortoiseSVN
Related
We use Visual Studio to write and maintain native Windows apps. We are looking into using NuGet to handle our dependencies, which consist of native static libs.
After some research, I've managed to use NuGet, package.config and the CoApp PowerShell scripts to create and consume NuGet packages with native libs in them. The issue we're facing right now is that we need to have Snapshot support.
The rollover PreRelease mechanism (with * for version rollover) that NuGet 3 and onwards supports looks great, however, it seems to only work with project.json and not with package.config. Project.json, however, doesn't seem to work with native packages, as they don't get installed in the local solution folder so the build can't find the headers and libs.
The question boils down to:
Is there a way to use project.json and NuGet 3 with native static libs?
If not, then, what alternatives are out there to support this use case? (The use case being build-time dependency distribution for native, unmanaged Windows static libraries).
EDIT:
At the end, we decided to use Maven for dependency management since NuGet doesn't seem to support our use case. I filed an issue about two weeks ago but it hasn't received any response. However, if we had decided to force NuGet into our use case, the solution proposed by Wendy would probably be the way to go, so I'm accepting it.
There are two ways could add content files into project that uses project.json file. One is "contentFiles" node and another is "files" node in nuspec file. Detailed steps please refer to:
http://blog.nuget.org/20160126/nuget-contentFiles-demystified.html
But please note, these ways only support UWP and Portable class libraries.
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
1.UWP apps
2.Portable class libraries
The contentFiles option is not available for other project types
If you are using .NET Core application or other type project that use project.json, the content files in nuget package is not supported added into project at present.
We have an asp.net c# web site in team foundation server. Our project includes a number of 3rd party dll's, that are located under bin/ folders of all developers. We are trying to adapt a build strategy, by using build definitions in tfs.
We tried to build the project in a different server than a develeoper computer, and the build failed, since these dll's do not exist there.
My question is; how do we put those dll's to build definition?
Hope I made myself clear, since we are apparently novices in tfs build services :)
Thank you all.
Thank you for your answers. Actually, we studied on it further and found a solution as follows:
Put dll's into _bin_deployableAssemblies folder under web application (name of this folder is important)
In the MSBuild Arguments part of the build definition, add /p:ReferencePath=""
That solved the problem. Thank you again in advance.
You can either (#1) make these 3rd party DLLs available in the server that does the build, or (#2) check them in into the source control.This is a discussion that has occurred several times in the past, in general the most advisable thing to do is proceed with option #2 .
Here are some further similar questions in SO, that might be useful to you:How to deal with external assembliesTeam Build 2010 - Third Party Assembly References not copying to output folderVisual Studio Package build and DLLs in private bin path
You will need to add the files into the Source Control repository. In our solution we have a \3rd Party folder that contains all of the 3rd Party assemblies that our projects references.
\Main
\3rd Party
\Application
\Modules
\etc.
In regard to Kemal Taşkın's response, great answer! Note that sometimes you need to leave a trailing '\' when using /p:ReferencePath=""
For example:
/p:ReferencePath="path\to\commondlls\"
For whatever some versions of MSBuild.exe remove the last '\'.
This also solved my problems using the TFS 2015 MSBuild Task's MSBuild Argument field.
I've just found the C5 library for .Net. I would like to 'install' it in a way that I can easily add a reference to it from all my c# projects. I found some information pointing to the global assembly cache. However I'm worried that the binary will only run on my machine. How do I know if VS includes the C5 .dll in my binaries?
Thanks.
EDIT:
Also I have a personal library I use for all my projects. Would it be possible to export the C5 library from inside my own?
I just normally create a solution folder in the root of the solution and add the assemblies there.
This allows you to easily reference them and have them under source control.
For a specific project, you could include the DLL in the Visual Studio project and reference it there. The DLL will be checked into source control and will be available to other developers when they check it out. It will also be available to the build server.
If a single DLL must be shared between multiple projects then there are other strategies that involve branching for example. See this guidance from Patterns and Practices for more details.
I'm working on a VS solution with 100+ projects in C#. I'm currently migrating it from VS 2008 to VS 2010. There is some work to be done because a lot of the projects use Enterprise Library 4 (which has to be upgraded to 5.0) and WCSF 2008 (which has to be upgraded to SCSF 2010). I'm going through the SCSF upgrade instructions, and one involves doing this:
Add a reference to the following
Service Location assembly in each
project that has a reference to an
Enterprise Library assembly.
Microsoft.Practices.ServiceLocation.dll
Is there any way to do this without going through the IDE? I mean, opening up each of 100-odd projects, then checking the references, then adding a reference if necessary, is one way of doing it, but is there a faster way? I was thinking along the lines of doing a search over the project files for a particular reference, then doing an insert if it was found.
If you've done this kind of thing before, suggestions would be very welcome. Thanks.
If you want to do this through the IDE, you can write a macro using VSProject.References to add/remove references as necessary.
However, C# project files (.csproj) are just XML, so you may be able to write a simple utility that can adjust the file as necessary using the standard XML classes.
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.