Develop Reference

How to prevent Visual studio loading dlls from diferent path of his project refrence path

I've noticed that Visual studio looks for a referenced dll anywhere (other projects, GAC, ...) if that dll isn´t in referenced path. It happens mostly with nugget packages.
Is there anyway to prevent this behavior?
I think this behavior is dangerous, because it gives you false security that your application has all refenreced dlls correctly, at the time of deploy app you can get a surprise.
Thanks

The .Net Framework does look in the applications directory or subdirectories, GAC and (if deployed to) on http server.
You can find the description here.
For GAC and http server the framework does require a strong name signing. So if your assembly is not strong signed the framework won't search there.
When deploying an app with release, this normally also should include a test installation on a non-development workstation (where no visual studio or anything else is installed). Additionally, checking that all dependent assemblies are deployed is another task of programming (at least, in my opinion).
Visual studio also does copy referenced nuget packages assembly to the output directory without any manual action.

What you're describing is not a behavior of Visual Studio but rather of .NET itself. The process of how and where assemblies are resolved is an intrinsic and essential part of the technology. So in my eyes, you are contradicting one paradigm of .NET.
However, you can use a couple of workarounds. This post contains Microsoft's description of how the .NET runtime locates assemblies. Thus you could try to ship around these manners, e. g. not signing assemblies would skip accessing the GAC.

NuGet or assemblies folder for shared 3rd party DLL's?

I have about 10-15 projects with separate solutions that reference 3rd party DLL's in a microsoft .NET shop. One of the problems that we want to address is consistency of the versions of the DLL's used across projects (E.G. Netwonsoft 8.0.3 in all projects as opposed to separate versions depending when the project was created).
I have seen this done in two separate ways in my previous positions and was wondering if there are any other options to solve this problem.
I have used a corporate NuGet for all third party DLL's referenced within a solution for any project within the company. The DLL's would be updated and then made available to the developers in the projects to pull down and upgrade (if needed) within the solutions on their own.
Another company had an assemblies folder in source that housed all "approved" third party DLL's and all references lived within this directory.
I did see this question but it only offered one of the two solutions above: Where should you store 3rd party assemblies?
Are there other options aside from the ones listed above?

Whenever possible use NuGet. Primary reason being that Git doesn't very much handle large binaries well and using LFS for this doesn't make much sense, since there is a valid alternative. TFVC has fewer issues with large binaries, but I'd keep future migration to Git in mind if you're on TFVC.
Keep in mind that not just NuGet, but likely also npm and other package sources are of interest in this case.
If you want to enforce a certain version being used, create a custom task that you hook into the CI pipeline. That way you can easily give off warnings or setup some kind of policy. The custom task could take the packages.config file, scan the referenced packages and then query the TFS/VSTS package management feed to see if it's using the latest version (or the is using the latest minor version)... (or is using at least x versions back)... or fetches the approved versions from a json file or xml file from somewhere and validates against that...

In your source control, Commit and Push to Master with the desired dependency DLLs when the repository is first populated. Since all users, even on other branches, will then be pulling from the repository, you're ensuring they receive all the DLLs they need. This only becomes a problem if you're referring to DLLs in the GAC, which is resolved either by GACUtil or just making sure everyone is using the same Windows version.

How to control multiple versions of ODP.NET

I have written a .NET 4 NT service which connects to an Oracle 11g database and now I wish to deploy.
The target machine has Oracle drivers installed but only for ODP v2. (I assume; there is only a 2.x folder in ODP.NET\Bin)
There is no upgrade path; company packages do not include what I am looking for, and I have no say in what should be included in those standard builds.
I am, on the other hand, permitted to install downloaded drivers ...
The target already runs 3 applications using the installed driver. It is a requirement that they continue to do so undisturbed.
So, with 2 sets of Oracle drivers installed, how do I ensure that my new application uses the new set whilst keeping the old set 'primary' ?

I assume both of the installers place the ODP assemblies in the GAC. If so, you can force use of a particular version.
Make sure you make a fully qualified reference in your .csproj files to the version of ODP you want to use. I don't know the specifics for the assemblies you need but here is an example of what the reference should look like in the csproj files. be sure it is Fully Qualified (has name, version, culture, publickey, architecture). And that SpecificVersion is true.
<Reference Include="ODP..., Version=4.x.x.x, Culture=neutral, PublicKeyToken=theKey, processorArchitecture=...">
<HintPath>..\..\..\lib\ODP\ODP.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
</Reference>
Once compiled, this will make references in your compiled code to specific versions. At runtime, the assembly loader will look for the version you request. Use Fusion Log Viewer to trace that this is happening as expected. If not you can implement assembly binding redirect in various ways.
Take a look at these links if you need to go this route:
Redirecting Assembly Versions
How the Runtime Locates Assemblies

You need to look at side-by-side deployment, as outlined in Oracle's technetwork
If this is impossible to do, for some reason, you will have to look at segregating the application or some other solution.

Should a dll be kept in folder or registered with gac [duplicate]

This question already has answers here:
When and when-not to install into the GAC?
(7 answers)
Closed 10 years ago.
Which is the preferred, to keep your library in the folder your executable, or to register it with GAC?

You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.
Refer: Global Assembly Cache
Also, Refer GAC vs BIN

See the discussion here: Why should I NOT use the GAC?
TL;DR - it depends on your needs and preference. For most uses, I personally avoid the GAC.

If your assembly (dll) is just for use by your application, install it in the same folder as the executable. This is usually the preferred method (and the majority use case).
If it will be used by many applications, possibly install it in the GAC. The GAC is really just for Microsoft assemblies.
I've recently written an application where I went one step further and merged the dll's into a single executable.
When and when-not to install into the GAC?
What are the advantages and disadvantages of using the GAC?
Embedding DLLs in a compiled executable

I'd register with GAC to avoid confusion and respective your binaries clean. You can technically do it either way, but the best thing to do is keep it in their respective paths. You should use all of windows environment paths for respective file types such as user data and DLL's, etc.
Also see if you want to reuse this library. For global use by other apps and libraries, etc put in GAC. For local use just for the exe put it in the same path.

Understanding IlMerge - how to pack an executable with all it's associated dll's

I know I'm not the first person to ask this question on Stack Overflow and I'm sure I won't be the last. But, after spending hours researching how to do this and then physically trying to do it, I'm near ready to give up.
I have a .NET Framework 4, C#, WinForms application that builds to an executable. I rely on many many many dlls. The dlls fall into multiple categories.
Libraries I have written with no dependencies of their own
Libraries I have written with dependencies on other libraries I've written
Libraries I have written with dependencies on third party dlls
Third party stand alone dlls
Third party dlls with their own dependencies on other dlls
So after I compile my application I have a directory with an executable and approximately 15 dlls.
I want to pack all the dlls into a single executable so that I can simply distribute a single executable.
I know that IlMerge is the typically suggested application to use for this, but I'm curious if there is something easier to use that is more intuitive and works accross both WinForms and WPF.

The problem here is that ILMerge only can merge .Net assemblies. Your file lame_enc.dll isn't a .Net assembly but a standard Windows dll and therefore can't be loaded by ILMerge.
To get around this you could embed lame_enc.dll in your assembly and then extract it when needed in your application. Check out this article for more info on that.
http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx

In the end, I went an entirely different direction.
I decided to use the Costura Visual Studio Extensions located here.
These extensions use a combination of two methods
Jeffrey Richter's suggestion of using embedded resources as a method of merging assemblies
Einar Egilsson's suggestion using cecil to create module initializers
What's nice here is that you simply install the extensions into Visual Studio. After doing that, for any project where you want to pack your DLLs into a single executable, simply select the project, click Project on the menu bar, Costura, Configure, and then OK. It will ask you to reload the project - click yes. Now whenever you build the project it will create just a single executable (or DLL if you are doing it on a library). Couldn't be more easy.

ILMerge only combines pure (not mixed-mode) CLR assemblies. It works by extracting all of the CIL modules and then relinking them into a single new assembly. Assembly resources are also recombined.
ILMerge cannot merge native executable code. lame_enc.dll is a native DLL file and does not contain any CIL modules, that's why you can't combine it.
If you want to pack your application into a single executable a workaround is to include lame_enc.dll as an assembly resource, then save lame_enc.dll to disk in a temp folder perhaps, and add the folder it was saved in to your application's PATH, so your [DllImport] runtime linker will be able to access it.

To address your exact issue, verify that the file C:\Release\lame_enc.dll exists and that it is in fact a .NET file. ILMerge can only merge .NET assemblies.
Now if you are only worried about distribution of your application, you may consider creating an installer to install all of the binaries, and not worry about merging them using ILMerge.
Another alternative to using ILMerge is to embed the binaries in an assembly as desribed here.