Please any one explain this. This Question helps to understand common things
Question:
What is the difference between when you 'add DLL reference from one project to another project via Browse Option and Add DLL reference from Solution project to another project and copy-paste from one project to another project'?
I have found an answer on google
Answer:
Adding a project reference adds a local project's DLL to the project that references it, and every time the solution compiles, the updated DLL for that project gets copied to the other project. So when you go through the build process, if you have 5 projects, each one rebuilds its DLL, and copies that DLL to its references.
But:
I don't know what the process is and the difference when we copy-paste from one project to another project?
When you do copy paste from One project to another, the dependent project add its reference of the file that you have paste in the project solution directory
When you do copy paste the dll of one project to the other project's directory and then Add its reference by browsing to that directory where you have pasted your dll. Then VS only add its reference and copy that dll to its bin folder and show you (allows you) all the method and properties that it contains.
If you do any change in your source project solution like adding or modifying methods then the updated dll of that project is not available in your dependent project solution.
So VS still points to the old dll file just because of the reference you added. So whenever you made any change in your source project solution, you have to add the reference of the updated dll to your dependent solution every time.
In Second Case: When you add reference of your source project into your dependent project solution, VS always take the most recent updated dll from your source project into your dependent project. So in this way you don't need to add reference every time you compile the code or debug.
When you just reference a DLL by browsing to it, VS would copy it to the output directory of the dependent project.
Suppose afterwards that DLL is updated - there is no guaranty that VS would retake that updated DLL, and copy it again to the output directory of the dependent project - which mean, that even after you fixed some bugs in the other project, those bug would persist in the dependent project (because it is still using the previous version of that DLL).
When you add reference to other project in the solution, VS would always take the most recent and updated DLL outputted from that project.
Related
Project A references Project B, and Project B references an external DDL (restored using NuGet). The DLL should get copied into Project A's bin folder (along with Project B's DLL):
In my case, when running Project A, I get the following exception thrown:
Could not load file or assembly 'PostSharp, Version=3.2.18.0,
Culture=neutral, PublicKeyToken=b13fd38b8f9c99d7' or one of its
dependencies. The system cannot find the file specified.
The DLL is not being copied into Project A's bin. All other external references from Project B are being copied across just fine, which is what is confusing for me.
Copy Local is set to true for all references involved. Example:
How do I do this?
Note: Using Visual Studio 2013.
The options that I found were to:
Add a reference to PostSharp in Project A.
Add dummy code in Project B so that the compiler would detect that the reference is being used.
Add a build event to force copy the DLL.
I don't like any of the above solutions. They are hacks in my opinion and will only make for a more unmaintainable solution in the long run.
I have fixed the problem by using a common output directory. This seems to be a recommended solution by many. I have also experienced much faster build times. See this Stackoverflow post.
When I ran into this problem it was because I changed a project's name, but did not change the assembly name - it was identical to the assembly name of another project in the solution.
I've added some dummy (unused) code on Project B, making reference to the DLL needed.
Thus, the compiler will guess that it must copy the DLL into project A output.
I am using VS2012 and I am seeing weird problem. I added a new project into my solution and that project was working all fine until now.
Now, Everytime I build/re-build the solution, i am seeing reference errors from different projects which are using that particular reference. I checked the bin/debug folder and assembly is not there.
Surprisingly enough, when I build that particular project by it self, it builds successfully and produces the assembly into bin/debug folder.
Now, it works when built alone but does not work when build in solution. And when I build entire solution, something causes the .dll file to be deleted somehow to cause all the references to break.
I have done following things so far:
Made sure this project is second one to be built in entire solution
Went through all the projects which I are depending on this project and added the dependency manually.
Any ideas on how can I solve this issue?
If the referencing project and the referenced project are both in the same Visual Studio solution then it is generally considered a best practice to use project references rather than assembly references. This ensures that build dependency orders are maintained automatically and helps prevent you from accidentally creating circular references.
Assembly references should only be used when you cannot add the project that created the assembly to your solution. When you do use assembly references (which I don't recommend in this case) you should put the assemblies into a common folder outside of your bin\debug folder structure to ensure you don't accidentally delete the file when, for example, you do a Clean operation.
I have updated a .cs file in one solution that is being used by a .cs file in a second solution in VS 2010. I have deleted the reference to the .dll file in the second solution and then re-referenced it but I'm still referencing the old dll. Is there something else I have to do in order to get the correct version? What am I doing wrong?
You have to build the solution that contains the modified .cs. After building that solution, then you have to build the solution consuming the dll. If you still have problem with it, then it is possible that your project is not marked for compiling. If that is so, right click on the project itself (not the solution) and re-build the project.
I have a C# project which references a DLL (call it external DLL) which comes with another application. When I build my project, due to the reference, the external DLL gets automatically added to my project output. And when I run my project it loads the external DLL from my project folder.
The other application, which the external DLL belongs to, is developed by another team and the DLL is regularly updated. I don't want to package their DLL with my project. Instead I would like to have my project load their DLL when executed -- rather than pick the DLL copy from my project's folder.
Now I know that this is possible through reflection. I know that I can do an "Assembly.Load" and pick the DLL. But because I use the types from the external DLL all through my code, I would like the code to be statically type checked.
Here's what I would like:
Be able to compile my project by referencing the external DLL and thus get static type checking.
When the project is run, the external DLL is picked up from the other application's folder and not the copy of the DLL which is in my project's output folder.
Is there any way to solve this problem? Is there some middle ground between adding a reference and using reflection?
The most immediete solution to your problem is to change the properties of the reference. There is a setting called Copy Local. Set that to false and it'll stop copying the DLL to your project's output. You can access the properties of the reference by expanding the references folder in your solution, right-clicking on the reference in question, and clicking properties to open the properties pane.
The fact that Visual Studio copies the DLL to your project's output folder at build time doesn't really matter to the .Net Framework at runtime. All that matters is that the assemblies you reference are available to the framework either in the paths it searches or in the global assembly cache.
I've got a C# project in visual studio that is building a DLL, and another console project which includes the first as a reference. These are both in the same solution.
The trouble is when I add methods to the DLL, then rebuild the console project doesn't seem to pick them up.
For example, in the DLL I have a class Converters. If I add a method
public static void test() {}
it just doesnt' show up in the console app at all. Intellisense doesn't autocomplete it, and if I manually type it in it gives a compiler error.
If I go in and delete the dll files then rebuild that works (or better yet, delete the bin and obj directories) but that seems rather drastic.
I'm sure this is a basic error, but I can't seem to find the solution after some googling.
How are you adding the reference? As a project reference or by browsing to the DLL? If you're using the latter then it will copy it locally to the bin directory of your console app and won't refresh it unless you manually delete it. If you add it as a project reference it will copy it as and when it needs to.
The exact thing happened to me once on a project - it turned out the build command wasn't configured to build these DLLs.
Check Build - Configuration Manager, and make sure the project is checked:
(Image from msdb - Setting the Build Configuration)
close Project visualStudio and
rebuild again your dll (other project visualStudio)
One of the things to note is the Target Framework of the Projects, if you compile your Project A with target framework different then that of Project B and it is referencing the dlls of Project A you may run into this kind of trouble. So, make sure that the target framework for both Projects is same.
Check that you don't have the ddl inside the bin folder of your project. Whilst I was adding the reference by browsing for the dll, I had forgotten that I manually copy pasted a version into that folder. No matter how many times I cleaned and rebuilt, it didn't seem to update.
Deleting that dll and re-referencing fixed the issue.
Change the reference to the dll to the Project, instead of the output.
This is certainly unexpected behavior. It sounds like the reference between the two projects is broken in some way. Two issues come to mind.
Possible problem with the reference. Try deleting the reference in solution explorer and readding the reference and seeing if that fixes things. When you re-add make sure it's a project reference and not a file reference.
It's possible that the time stamps on the files in your project are off. See if they are in the future.
check the folder which contains the reference. does it contain a refresh file with a relative path in it? if so, and if assembly names in the location pointed to by the relative path are common with those in of (project) references which should auto update, then these references no longer auto update! what you end up is a static reference to the assemblies present in the relative path contained in the refresh file.
you may also have to delete the projectreferences key in the sln file and add references afresh
I hate to beat a dead SO question but 8 years after the original question and none of the above solving the issue for me, my problem was in VS2013, but to solve it I simply removed and re-added the reference to the DLL in the project that invokes it.
I hope this helps some people in the newer VS realm having the same issue.