I need to copy standard component DLLs into a standard folder defined in every VS2012 project when the project is opened. We're not allowed to store DLLs in Subversion so I need to reload this folder every time a developer opens the project/solution. I'm looking for an automation solution that will pull DLLs from a centralized location and copy them into the developer's solution. I looked at Visual Studio Extensions but it seems like an awful lot of work just to copy a couple of files. Are there any other hooks in VS2012 (and hopefully VS2010) where I can code simple PowerShell scripts to copy these files?
It turns out AntHillPro has it's own functionality for storing common DLLs and loading them into folders in your Solution before building. It's not as elegant as an MSBuild pre-build task but it fits in with the model followed by our Java builds with some slight tweaking.
Why you just do no use Nuget? Adding nuget reference and enable nuget restore on build will do exactly what you need. You can create nuget repository as shared folder.
Related
Cross platform Xamarin Forms project in Visual Studio and Visual Studio for Mac. The project references Akavache. Akavache has a dependency of akavache.sqlite3. I have made a custom change to a DLL in the akavache.sqlite3 repo and built the DLL locally, and would prefer not to have to switch the whole Akavache package tree over to a custom build for all the Akavache dlls and dependencies. So essentially...would like to continue referencing the NuGet package like normal but "substitute" one DLL on the fly. Or something equivalent like that!
But it needs to be portable too. At first I used a post build copy command to overwrite the "standard" dll that gets put in the TargetDir. That works in the sense that it copies to TargetDir, but for Android copying the DLL into the TargetDir does no good. The DLL is already incorporated into the APK in the TargetDir instead. So it would need to happen some other way. Same basic issue if you used MSBuild instead of a post build command line.
Any thoughts?
FWIW, my current workaround is to copy the DLL over top of the cached NuGet package location. But the problem with this approach is anytime the cache would get cleared/updated it needs to be reapplied. That's also not an obvious step to do, or easily automated, when another developer want to get set up on their machine.
Any .nupkg files are just ZIP files with some metadata, so you can change at the contents. The NuGet Package Explorer should make it a little easier to view the contents.
The NuGet Gallery (e.g. https://www.nuget.org/) has a "Download" link on the left hand side, otherwise just install the package into an empty project and then take a peek.
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?
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
When I develop my web applications in Visual Studio 2010 I use tools such as GhostDoc, SandCastle, AJAX Toolkit, Moq, etc...
I usually use these tools in all my projects. When I downloaded the Moq tool for instance, I had a zip file with inside a couple of assemblies. Therefore, after unzipping the file, I added the relevant assemblies within the folder (in the file system) of the project I was currently developing, and then I referenced the dlls from Visual Studio.
Now the problem, or better organizational drawbacks, with this are 2:
1) I placed the assemblies within a specific project folder. That's ugly, since I would like to put the assemblies in one folder common to all the projects. Where do you usually put them?
2) Everytime I start a new project I need to reference all the assemblies over again. This, especially with the Ajax Toolkit is quite annoying. Is there any way to tell Visual Studio to add a set of predefined assemblies everytime I create a new project?
For the popular tools you can use NuGet. It will help you manage both the downloading, updating and removal of tools and referencing the appropriate assemblies.
Of the ones you mention, I found the following ones in the official NuGet packages repo:
Moq
AjaxControlToolkit
I have about 15 projects in a solution, and all of them have some broken third-party dll references. How do I configure VS to look for dlls in one specific directory? I am trying to compile and link my project, but it doesn't work because projects have broken references to existing third-party dlls. My solution consists of C# class library projects and an ASP.NET web site.
If they are project references (and they probably should be), you should not need to (unles you have moved the projects)
Otherwise, create a third-party Lib folder (under source control) at the solution root folder, place your third-party DLLs in it and reference from there.
If you need to fix up references, download and install VSCommands 2010 which has a very useful copy and paste references feature (among others). [Fix up for one project, and then simply copy and paste to other projects. Failing that, you would need to manually edit the .proj files, using Powershell for instance.]
You go from one project to the other and update the references to point to the new location.
If this is a third party DLL, you can record a macro the first time you do this and replay it for each project.