We Keep Coding

Whether or not to include external DLLs in C# project

Our project has a lot of external DLLs, most but not all of which are 3rd party DLLs.
Currently we do not have these DLLs included in our project. They are included in SVN and given a path to our build output directory. So, after building our project the neccessary files are there, because of SVN, but the project itself has no knowledge of them.
My feeling is that we should have a folder under the root of our project named something like Dependancies or ThirdParty with all of the DLLs included there and set their build event to copy to the output directory. They would exist in SVN as well, but in the same structure as the project, not in the build output directory.
The project itself only references one of these DLLs called CommunicationProc.DLL. The CommunicationProc.DLL then references all of the other DLLs. We have numerous DLLs to support different types of radio. So not all DLLs will be used, but any one of them may be used depending on the radio type.
As to whether or not the DLLs should be included in the project we have differing opinions internally, some of the team beleives they should only be in SVN and not part of the project itself.
Of note is that this are not .NET DLLs, most are old C DLLs.
What is the accepted practice? Can someone please provide me with a compelling arguement one way or the other as to whether to include them in the project or just SVN?

Its better to have them in a folder on source control and then copy them over to the debug folder on build event. This way you can manage their versions. If a newer version of some dll comes then you can replace the old one and put some comments with check in. Also if you are working in a team, then instead of copying files from debug folder to each team member, you can let each team member to use the same set of dlls from source control. If you are developing some control and want your customers to use that control then its easier for you to have a set of dependent dlls some where so that you can give those to your customer along with your .Net dlls.
I had the same issue with some un-managed dlls and ended up putting them in a folder so that all the team members have the same version of the dlls. Hope this helps.

I include a project that has no code but contains a folder where all the external assemblies and their dependencies are kepts. For each file set the Build Action to None and Copy to Output as Do Not Copyp. The project then references the binaries from this location. In your other projects, reference this special project. When you build, because the special project is referenced and it references all the needed dependencies, the binaries are copied as needed.
If you do not want a special project, still create the folder in your main project, added the assemblies, set their properties, then reference the assemblies as needed.
This gives you complete control over the versions and output, and more importantly, it is simple.

Cannot reference dependency assemblies in T4 template when using TransformOnBuild

We're trying to use T4 with Visual Studio 2010 (SP1) to build scripts for another language that are based upon some of our existing C# classes. I'm hoping for the following:
The template needs to load our existing assembly and use objects from a namespace in that assembly.
The transformation needs to run on every build on every development machine and build server without any additional installations.
(1) and (2) need to work together.
(1) was fairly straightforward:
<## assembly name="$(TargetDir)RequiredProject.dll" #>
<## import namespace="RequiredProject.RequiredNamespace" #>
Using the $(TargetDir) macro allowed me to reference the dll with a fully qualified UNC path (per the instructions found here).
(2) is a bit roundabout, but I think I've got it solved: I installed the required text transformation SDKs on a different machine and copied the required .targets and .dlls into a folder in my solution and then updated my .csproj file to reference the local .targets file.
(3) is where I run into problems. It seems like the <TransformOnBuild>true</TransformOnBuild> property doesn't play nicely when a referenced assembly needs to be built prior to the transformation. Everytime I enable transform on build with referenced assemblies, I get the following error:
Compiling transformation: Metadata file '$(TargetDir)RequiredProject.dll' could not be found.
However, I'm using the same assembly instruction that I was using in (1) to reference the assembly. In fact, going to the .tt template directly and saving it still produces the expected output -- it just doesn't work during the "build" step. Am I doing something wrong, or is there a way to ensure that the template transformations occur after the assemblies they depend on are built? (Or, more simply, that template transformations occur last?)

Unfortunately, the msbuild T4 host doesn't yet support embedded macro or msbuild variables in assembly names.
However, it does support Windows environment variables "%foo%", so although it means some machine-level setup, you can get something that works across in-IDE and build time transforms.

My understanding is that Visual Studio 2013 will finally solve this problem, but that doesn't do me much good as I'm still on Visual Studio 2012. After a lot of effort I finally ran across a solution.
In the project that has the template you wish to run, add the following as a pre-build step on the Build Events tab of the project properties page.
set textTransformPath="%CommonProgramFiles(x86)%\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\TextTransform.exe"
if %textTransformPath%=="\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\TextTransform.exe" set textTransformPath="%CommonProgramFiles%\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\TextTransform.exe"
set ProjectDir=$(ProjectDir)
%textTransformPath% "%ProjectDir%StringGenerator.tt"
The first two lines take care of the differences between locating TextTransform.exe on 32-bit and 64-bit systems. The third line is the key. I need the path to the project location inside my template, so I set a local environment variable equal to the value of the build's $(ProjectDir) property. Inside my template, just use the following:
var projectDir = Environment.GetEnvironmentVariable("ProjectDir");
This has solved my issue.

I created a seperate solution that contained my needed referenced assemblies. The I had my buildscript build the reference solution first, then transform the templates, then build the solution containing the generated code.

If you want to reference dependency assemblies within a T4 script using macros and have text templating succeed during build-time, then you have to use project properties.
Within your project:
<Import Project="$(ProgramFiles)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets" />
<PropertyGroup>
<T4ProjectDir>$(ProjectDir)</T4ProjectDir>
</PropertyGroup>
<ItemGroup>
<T4ParameterValues Include="T4ProjectDir">
<Value>$(T4ProjectDir)</Value>
<Visible>false</Visible>
</T4ParameterValues>
</ItemGroup>
Where the path to your text templating environment may be different.
Then use $(T4ProjectDir) as you would use any other macro in your text template.
Or you could also simply refer to existing properties:
<ItemGroup>
<T4ParameterValues Include="ProjectDir">
<Value>$(ProjectDir)</Value>
<Visible>false</Visible>
</T4ParameterValues>
</ItemGroup>

How to save DLLs in a different folder when compiling in Visual Studio?

Let's suppose I have a Window Forms / Console Application C# project with some external references and references to other class library projects in the same solution too.
When I build the Window Form project, I want the referenced libraries be stored in a different location (eg: bin\Release\Libraries), and not in the same folder as the .exe.
Is it possible to do?

There are 2 parts of your question:
How to configure solutions to build assemblies/EXE into folders of your choice - this is configured through properties of the project in VS (project properties -> build -> output path). Also value of check "copy local" property on each reference.
How to load assemblies files from non-default locations (i.e. from your ...\Libraries folder) - you need to make changes to your app.config file to add this non-default paths to assembly search location..
Link to Microsoft site no longer works, so summary from wayback machine: How to load an assembly at runtime that is located in a folder that is not the bin folder of the application:
Method 1: Install the assembly in the global assembly cache (GAC).
The GAC is a computer-wide code cache where the common language runtime is installed. The GAC stores assemblies that you specifically designate to be shared by several applications.
Note You can only install strong-named assemblies in the GAC.
Method 2: Use an application configuration (.config) file with the tags
A .config file contains the following settings:
• Settings that are specific to an application
• Settings that the common language runtime reads, such as the assembly binding policy settings and the remoting objects settings
• Settings that the application reads
The <codeBase> tags specify where the common language runtime can find an assembly. The common language runtime applies the settings of the <codeBase> tags from the .config file. The settings of the <codeBase> tags determine the version and the location of the assembly.
Method 3: Use the AssemblyResolve event
The AssemblyResolve event fires whenever the common language runtime tries to bind to an assembly and fails. You can use the AddHandler method to add an event handler to the application that returns the correct assembly whenever the AssemblyResolve event fires.
The AssemblyResolve event handler must return an [Assembly] object, and the common language runtime must bind to this object. Typically, you can use the Assembly.LoadFrom method to load the assembly and then to return the object.

Correct answers were given earlier. I'll just mention that there is a nuget package for this called PrettyBin.
Install it on your startup project. DLLs and XMLs will go to a lib folder and you'll have a working example of how it's done, if you won't to customize.

Set Reference path in project peoperties.
You can also specify where your compiled exe goes by specifying Output path in project peoperties.

You'll find best practices for organizing project references here: http://codebetter.com/patricksmacchia/2009/01/11/lessons-learned-from-the-nunit-code-base/
Look under chapter "The VisualStudio Project Reference + Copy Local true option is evil!"

Yes it is possible, you'd do it in your msbuild script. While I can't give you an exact answer, look here at this question on SO Copy all files and folders using msbuild

Cannot use external references with C# Console Application

I have tried all the suggestions below but still no joy.
I'm now trying a console application, and let me explain exactly what I'm doing.
I create a new console project in VS 2010
I add a number of references (dll's) some that aren't mine such as Castle.Winsor and N2 CMS dlls
in the console app I can add using statements indicating I am using name spaces within the referenced DLLs
I start writing code.
As soon as I compile all the code that uses the referenced DLLs immediately complains with "The type or namespace name '' could not be found (are you missing a using directive or an assembly reference?)"
I have tried setting the dlls to copy to local always, I have copied the DLL into the same directory, I have tried added reference by project and adding a reference to the DLL's themselves
I don't get this problem with a web application project or a ASP.net project they always work fine, only something that is compiled to an EXE like a console app or windows service.
there must be something I'm missing or I would have got this working by now.

Change the project Target to a non Client Profile target. Right click the Project and select Properties, you should see a list of Framework versions. As you are using VS2010, the Console project you've created by default targets .NET Framework 4.0 Client Profile, change that to .NET Framework 4.0.

Check if Copy Local is set to true for the referenced assembly.

First, as to your question, its hard to know exactly what you're doing wrong, but from the fact that you're using an underscore in an assembly name (and probably in namespaces and type names), it suggests you're rather new to the .NET world.
This suggests that you're adding references to other projects in your solution by browsing to the compiled assembly, rather than by adding a Project Reference. When adding a reference, you must select the Project tab rather than browsing for the assembly.
Even if you don't believe this is the issue, remove all references and re-add project references to make absolutely sure. Assumption, asses etc.
Once you've done that, I'd strongly suggest remove all the underscores from your types, namespaces and assemblies. You might want to go read the framework design guidelines, too.

Open your .Proj(Windows service project file) file in notepad and check whether your assembly location(data_object) is the same which you are pointing.
When you open .Proj file in notepad you can check for,
Project reference,
<ProjectReference Include="C:\StackOverflow\StackOverflow.csproj">
And if you giving dll or exe refrence then
<Reference Include="StackOverflow, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86">
<SpecificVersion>False</SpecificVersion>
<ExecutableExtension>.exe</ExecutableExtension>
<HintPath>C:\StackOverflow\bin\Debug\StackOverflow.exe</HintPath>
</Reference>
I suggest you to give exact location including drive name like above example.
Other option you may try,
1. Clean and rebuild
2. Add Project reference if you already tried dll reference
3. Check whether the folder (referred assembly location) is Read Only then remove it.

In VS 2019, I had two projects, one C++ and other one C# Console in one solution file. When tried to add a dll reference through "Add reference", I was not able to see Browse button in "Reference Manager" window, to select dll file.
But when I created only C# Console app inside solution then I could add dll reference.

Optimizing Visual Studio solution build - where to put DLL files?

I found out that build time of C# solution with many projects gets much faster if you don't have "copy local" enabled everywhere. I did some tests and it seems that (for our solution at least) we could increase build time by factor 2-3 just by removing "Copy local". This probably means we have to store libraries in some common directory.
Any suggestion/best practices how to acheive this? Note that I would like to keep references to projects, not to DLLs.

We retarget the output directory of projects to be ../../Debug (or ../../Release)
Our libs are placed in these directories as well.
We set the reference paths in each project to be the Debug or Release directory accordingly (this setting is persisted in the user files since it is an absolute rather than relative reference)
We keep project references as project references, All dll references have copy local false and specific version false unless they are system level dlls we know will be in the GAC on all deployed machines.
This works a treat and manual builds in the IDE mimic scripted builds from the command line (using MSBuild)
Test projects not for deployment do not direct their output to the centralized Debug|Release directory, they just use the standard default location (and do use copy local to avoid issues with locking)
The library versions may be changed by the automated build process replacing the dlls in the Debug and Release directories.

I recommend building to ..\..\Build if your application is spread across solutions. (If you only have one solution, you may consider ..\Build.) Visual studio will, by default, pick up reference files in it's output folder. When building without VS using MSBuild, though, you must add the build folder as a reference path as shown in the example below:
<Target Name="BuildApp">
<MSBuild
Projects="#(ProjectReference)"
Targets="Rebuild"
Properties="ReferencePath=..\..\Build;$(LibraryFolder)" >
</MSBuild>
<OnError ExecuteTargets="BuildFailed" />
</Target>
The example also takes me to my second argument. I do not think you should use your build folder as library folder, since this may lead to individual projects erroneously overwriting library assemblies e.g. by using Copy Local. You should have strict control over your library versions, so I suggest you keep this separated. (Developers would need to add this path in VS as a reference path.)
You may also choose to separate ..\..\Build into ..\..\Release and ..\..\Debug as suggested by ShuggyCoUk.

I like the top level Bin Lib folder setup that is common in Unix based systems, by the way moving to this type of system will also make your release engineer's life a lot easier as well. Installer Creation is much simplified by only having to pull everyhting out of one folder. Dll's would then go in bin..