Manage output Files and Folders (Debug/release) in VS C#.

Question

1.00/5 (1 vote)

See more:

Hi Friend,
in VS when we add a reference of external library in our "project references" (and set "copy Local" property ="True") then after debuging it adds a copy of the .dll library in debug folder like this "..\bin\Debug\Aforge.dll".

My question is that can we do something like that it copies the referenced dll file in some other folder. like this "..\bin\Debug\NewFolder\Aforge.dll" ?

or can we use external libraries without adding reference
like;
using "path\Aforge.net";
so that we can use a folder with libraries and use them in code.

I am trying to manage output files of my project. thanks

Posted 31-May-13 4:17am

Member 8973214

Updated 31-May-13 4:26am

v3

Add a Solution

Comments

Sergey Alexandrovich Kryukov 31-May-13 10:48am

It depends on how you want to deploy it. If you want to deploy it somewhere with just your product, you have to supply AForge.NET anyway; it should be copied to the customer's executable directory anyway. Or installed to GAC, for universal reuse.
—SA

Member 8973214 31-May-13 11:22am

yeah SA thanks.

Sergey Alexandrovich Kryukov 31-May-13 11:37am

Sure.
Good luck, call again.
—SA

3 solutions

Solution 3

[This is the alternative solution is response to Solution 1]

The advice about using Assembly.LoadFrom per se does not provide a solution the way the referenced assemblies do. The functionality is quite different. Dynamically loaded assembly cannot be used directly, because its definitions cannot be used in the code of host assembly: they do not exist at compile time. Such assembly still needs some interface(s) to its types, known at compile time, otherwise using its types and members would be pointless, on the "call who knows what who know why basic". But with the interface(s), its possible to validate that the dynamically loaded assembly implement them and reliably call appropriate methods/properties.

So, the functionality is quite different; in return, this approach is great for development of all kinds of plug-in/extension architectures, and the like. I discussed the whole bunch of the problems and solutions in my past answers:
http://www.codeproject.com/Answers/168158/Create-WPF-Application-that-uses-Reloadable-Plugin#answer1[^],
http://www.codeproject.com/Answers/181392/AppDomain-refuses-to-load-an-assembly#answer2[^],
http://www.codeproject.com/Answers/169630/code-generating-using-CodeDom.aspx#answer5[^],
http://www.codeproject.com/Answers/168158/Create-WPF-Application-that-uses-Reloadable-Plugin.aspx#answer1[^],
simple part of it: http://www.codeproject.com/Answers/215165/Dynamically-Load-User-Controls#answer1[^],
http://www.codeproject.com/Answers/324060/Csharp-Reflection-InvokeMember-on-existing-instanc#answer1[^],
http://www.codeproject.com/Answers/443680/Gathering-types-from-assemblies-by-its-string-repr#answer1[^].

—SA

Posted 31-May-13 6:14am

Sergey Alexandrovich Kryukov

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-05-31T05:09:00

This is how it is resolved in most general (custom) case: http://msdn.microsoft.com/en-us/library/ff527268.aspx[^].

However, I wouldn't advice your to go for it. Please also see my comment to the question.

I personally do just the opposite: I put the source code of AForge.NET in the same solution with my application projects, and I references the assemblies by project (the "Projects" tab of the Visual Studio "Add Reference" window), which give me an additional abstraction layer, should I change some paths, the build is not destroyed. Additionally, it gives me the opportunity to vary Platform/Configuration of the whole solution by one common option. (Moreover, at this time I use the custom AForge.NET build, only some subset I really need; and I manually assembled the AForge.NET project out of separate source files. Not to recommend it, just to give an idea that this is easy enough.)

By the way, one more advice, not related to the question, but in neighboring area related to project/solution setup:

By default, when you add projects to solution, output goes to individual "bin/Release", "bin/Debug" directories per project. When some assembly depends on others, all required dependency assemblies are copied to its output directory. This way, you end up with multiple copies of the same assemblies after the build. This is very redundant, by why is it so? Microsoft does it for one purpose: to make all added and depended project "work right away". This is not your goal in an advanced product. So, I modify all output paths to some common directory on top. Like this: "../../bin.$(Configuration)" or even, when some platform-dependent solutions "../../bin.$(Configuration).$(Platform)".

(To make different platforms compilations for the same .NET project, you need to use Configuration Manager; I hope this is not within your scope now; it's always the best to use "AnyCPU" platform in all cases when it is possible.)

Now, the problem is: if you do it through Visual Studio, such path using MSBuild property references ~~will make '$' be escaped (!)~~ won't be resolved into the property value, so such "macro definition" if the path won't work (but it does work for C++). The workaround is simple: 1) in Visual Studio, manually enter "../../bin.Release" and "../../bin.Debug" (for example), per configuration, or 2) alternatively, use some text editor and manually enter "../../bin.$(Configuration)" in the project file. When you activate Visual Studio, it will request reloading the project, after it is reloaded, it will work as desired.

—SA

Ron Beyer · Accepted Answer · 2013-05-31T04:26:00

Solution 1

Not really, and its because of how .NET assemblies resolve references. The runtime first looks in the GAC for the referenced assembly, then if it doesn't find it there it will look in the same folder that the referencing assembly is in. If it doesn't find it there, it throws a not found exception.

The only way to do this is to dynamically load your assemblies through the Assembly.LoadFrom methods, then you can create a folder in your project, put the DLL's in that folder, and then set the Copy To Output Directory to "Always" or "Copy if newer" in the properties for that file. Also make sure to set the Build Action property to "None" so its not built into your executable. Although, I do think that this is more trouble than its worth.

Posted 31-May-13 4:26am

Ron Beyer

Comments

Sergey Alexandrovich Kryukov 31-May-13 11:12am

This is not exactly so: custom resolution of assembly referenced is quite possible. Please see my answer.

However, this technique is advanced and I don't see if it gives sound benefits, but apparently has drawbacks. So, I don't really recommend it. In practice, being incomplete, your advice is still quite reasonable. I voted 4.

—SA

Ron Beyer 31-May-13 11:36am

I think the link you posted is a little off (for AssemblyResolve event), here is how the .NET framework resolves assemblies: http://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.100).aspx. I guess additional information can be done in the application configuration file as per the expanded "Step 4" reference here: http://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.100).aspx, but this seems to apply mostly to ASP.

Sergey Alexandrovich Kryukov 31-May-13 11:39am

OK, thank you. As I can see, my point it taken anyway...
—SA

Member 8973214 31-May-13 11:15am

Thanks RB, I'll try.

Sergey Alexandrovich Kryukov 31-May-13 12:15pm

By the way, your advice about Assembly.LoadFrom is not quite accurate. It does not provide features similar to referencing of the assemblies. It has its own values, but very different ones. I explain it all in my Solution 3, please see.
—SA