I just recently came across the Visual Studio option to reference files as links. I think I groked the basic concept and also used it myself once. However, when I realized how nuget leverages this feature in the bootstrapper I found myself wondering what's the benefit in contrast to proper layering and referencing another assembly?
Can anyone point out the benefit of using linked classes against layering + referencing another assembly here?
To have less dependencies. The intent of the NuGet bootstrapper is to have the minimal amount of logic to bootstrap nuget.exe without having to duplicate alot of the code (that's why certain files are shared). In this particular case, we didn't want to have an unnecessary extra assembly, the nuget bootstrapper is a single exe.
Related
Using .NET Core, is there a way to have content-only projects in Visual Studio 2017 (no output dlls but automatic copying of content for other projects)? I'm after essentially the same thing as this post, save that I'm working with .NET Core.
I saw something about Shared Projects and wondered if that'd be the appropriate solution. Not exactly sure how they work with .NET Core, though (or if they're even supported).
I did some digging into how Shared Projects work. This appears to be exactly what I'm looking for, provided I don't encounter any major caveats or showstoppers down the road.
For others that are new to Shared Projects, they appear in a separate selection below Projects in the navigation tree of the Reference Manager (when adding project references).
We've just switched from SVN to TFS 2013, and I'm trying to set up a new gated build.
The project I'm currently working on has a couple of "referenced assemblies": DLL's it's dependent on which are fixed in place and don't have a nuget reference. As soon as I tried to compile my new build, it failed complaining it couldn't find these DLLs.
I assumed the answer was to include them in the solution somewhere. Which is fine, except that using solution folders appears to be a flaky, error-prone and rather rubbish way to fix things, as per Storing referenced Dlls in visual studio solution folder
However, that dates from 2011. Are there any better and more reliable ways of achieving this?
Don't discount the nuget option so quickly :) If there is no publicly available nuget package available you can wrap your assemblies in your own nuget package using the nuget package explorer:
https://npe.codeplex.com
Does the fact that you mention nuget mean you're already using nuget for other references? If so mdkes sensd to stick with it. Also are these reference assemblies third party or built internally?
I wrote a control library using visual studio 2010, I'll call it MyLibrary. MyLibrary references another control library I have that we'll call AnotherLibrary. I also have a clean virtual machine (CVM) and I've added AnotherLibrary to the GAC on the CVM. Using the CVM, I create a new WinForms project, add MyLibrary.dll to the toolbox, and drop one of the controls onto the form. Visual Studio will add MyLibrary.dll AND AnotherLibrary.dll to the references, even though AnotherLibrary.dll is in the GAC (and isn't needed). I can remove AnotherLibrary.dll from the references and everything is fine.
Is there a way to prevent visual studio from adding AnotherLibrary.dll in this scenario?
Edit: I've given this some thought and I have an example. When you add a TabControl to a parent control in the designer, visual studio won't add System.Design to the references, even though the TabControl depends on it. So, surely there is a way to do this?
You still need the reference. Just like you need the reference to, say, System.dll which is also in the GAC. You just don't need the copy of the assembly in your bin\Debug directory. That you happened to not break the compiler by removing the reference is possible, especially since is this is an indirectly used assembly. But some odds that you'll eventually run out of luck.
In general you really want to avoid using the GAC on your dev machine. Because you care about specific versions of an assembly when you, say, create a bug fix. You get those specific versions from source control, not the GAC.
Doesn't it make sense that it would automatically include all dependencies? It cannot assume that AnotherLibrary is in the GAC on every machine you might want to deploy your code on. Of course as you mentioned you can manually remove it....
We have a rather large VS 2010 solution that contains several C++ projects depending on each other. Most of the projects create static libraries that are linked in the final build steps.
I now wonder if there is a way to let the VS 2010 build system figure out include and library directories automatically. At the moment, I have to add the include directory of any lib I would like to use in the Additional include directories project setting. Is there a better solution to manage static library dependencies without having to specify all those directories manually? As Visual Studio already knows about the dependency between projects, why can't it determine those paths by itself?
The "better way" is to organize your static libraries better so that finding your headers is easier. VS cannot go out and randomly find the right headers for you. If it were to even try, there's too great a risk of multiple projects having headers of the same name (in different locations, of course), and the compiler using the wrong one.
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.