I am building this project and i have an external dll . I want to add a reference to it from the root reference folder . I have not tried though if its wrong.
But there is an obvious answer to this question across internet stating i have to referenc e the dll in the web.config assembly file .
I want to know why do we need to do so?
what is the differences between both ways ?
in the web.config section
The assemblies element defines a collection of assembly names that are
used during compilation of an ASP.NET application.
The assemblies element us usually used in web site projects as there is no project file storing location of references that the web site uses. The project references would not apply to a web site, as it has no proper project file to store these in, so must store all referenced assemblies in the web.config. There is some interesting, although not directly related, discussion here. In a web application project you can use both the assemblies element and project references.
Having a reference in the assemblies element also means you won't have to add the #register at the top of any .aspx pages that use that namespace. More discussion on that here.
Related
If someone could clarify the following, with regards to c#, this would be great.
Say I have a web project (webproj1) and a class library (classlib1).
webproj1 has a reference to classlib1.
classlib1 also has a reference to a third party dll (thirdpartydll).
When built, the \bin folder of webproj will obviously contain classlib1.dll, but should it also contain a copy of thirdpartydll.dll(which is referenced from classlib1) or is it somehow 'embedded' in to classlib1.dll?
You need it separately when the assembly cannot be found in for example the GAC.
See http://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx
You could embed it using ILMerge (http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx)
My WinForms 2.0 application has 2 assemblies. 1st assembly handles GUI and project specific code, and 2nd assembly is where I put all my reusable code. Both projects are part of the solution; 1st project references the 2nd project.
Now both the projects need to reference the log4net.dll file. Should I add a reference in each project pointing to the folder where I have downloaded log4net source code and built it; or should I copy the log4net.dll file into each project directory?
Or should I also add the entire log4net source code project as part of the solution, so that I am insulated from any future changes in log4net breaking my existing application?
One of the requirement is that future version changes in log4net which have potential risk of breaking existing code, should have minimum impact on my projects.
What is the best practice?
I am using C# 2.0.
Thanks,
I usually build the project and put the log4net dll in a libs folder which is a solution folder. Both projects reference this dll (libs folder).
Learn to rely on NuGet, it will automatically manage your dependencies and store them in proper folder.
As for log4net, the compatibility has already been broken because of messed keys and broken method contracts. No one knows how to resolve this mess:
http://netpl.blogspot.com/2012/03/pathetic-breaking-change-between.html
should I copy the log4net.dll file into each project directory?
No. Keep it at separate dependencies folder. This folder should be common for all projects in Solution. You should reference log4net.dll into each project (that require this component).
Or should I also add the entire log4net source code project as part of the solution, so that I am insulated from any future changes in log4net breaking my existing application?
It is not required. It is required only if you are facing any issues in log4net.dll and want to diagnose yourself.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does Copy-local work?
I have following situation:
there's a project named OLAF.Tools, and that project references Microsoft.Data.SqlXml in C:\Program Files\SQLXML 4.0\bin\Microsoft.Data.SqlXml.dll. Reference Copy Local property is set to True. When I build that project in bin directory I can see both OLAF.Tools.dll and Microsoft.Data.SqlXml.dll
there's a console application named OLAF.Generator, and that application references OLAF.Tools (I've added reference using Project tab). When I build that application in bin directory I can see only OLAF.Generator.exe and OLAF.Tools.dll - there's no Microsoft.Data.SqlXml.dll, what supprises me. Another wierd thing is that even though that dll is missing application is executing properly.
So my questions are:
why Microsoft.Data.SqlXml.dll is not copied to bin folder of OLAF.Generator console application?
how application resolves directory where Microsoft.Data.SqlXml.dll can be found?
Thanks,Pawel
EDIT 1: (after response from Marc Gravell)
#Marc Gravell: Your answer gave me food for thought, as I could swore that I could always see indirectly dependant assemblies in main application's bin directory. And IMHO I don't agree with you - with all due respect :)
Of course, references are not cascaded physically (we're are talking about strong relationship to classes, interfaces etc) - and it's exactly what I wanted to achieve when building OLAF.Tools library. That library provides a level of abstraction, it contains factories, and one factory accepts as a parameter string and returns interface. One particular implementation of that interface uses Microsoft.Data.SqlXml components. As a result,
OLAF.Generator uses interface that is located in OLAF.Tools, but doesn't know about components in Microsoft.Data.SqlXml.
Apart from that (I think we both know what I tried to explain in preceding paragraph), when building application, dependant assemblies should be copied (if Copy Local is set to TRUE). I just wrote sample application, Project B lib has reference to Project A lib, and Project C (console app) has reference to Project B. In Project C's bin directory I can see all: Project A.dll, Project B.dll & Project C.exe. So in discussed scenario, the reason why Microsoft.Data.SqlXml doesn't end up in OLAF.Generator bin folder has something to do with that assembly itself.
Does compiler/visual studio knows that Microsoft.Data.SqlXml is located in directory which is automatically probed (or it's in GAC) and this is the reason why that assembly is not copied?
EDIT 2: I've just checked GAC, and indeed, Microsoft.Data.SqlXml.dll is installed in GAC.
How does Copy-local work? log4net.dll is not being copied to MyProject output directory - this is answer to my question. When library is installed in GAC, it won't be copied even though COPY LOCAL setting is used.
References are not automatically cascaded, so adding a reference to OLAF.Tools does not also add a reference to SQLXML. If you want to deploy SQLXML with your exe, then the most convenient way to do that is to explicitly add a reference to SQLXML from your exe, and set it to copy local. Without this, it is not deployed. Basically, the onus is on the developer to decide which files are actually needed at runtime (which is often a subset of the references used, and depends on a number of deployment decisions which only you can know).
Re how it is resolved at runtime... the probing paths are a bit of a black art, mainly meaning "the app folder", but it depends on the config, and indeed the GAC may be consulted. You also get an opportunity to provide your own resolver, via AppDomain.Current.AssemblyResolve.
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.
I'm developing a Sharepoint application and use .NET AjaxControlToolkit library, we are adding a custom aspx page to the Sharepoint. Sharepoint 2007 run in quirks mode so I've made some modification to the AJAX library to make it behave like it normally should. The problem is, the other team already uses the AJAX library and it is a different version with mine. This caused conflict because there could be only one dll in the bin folder with the same name.
From what I know, .NET should be able to handle this situation easily. I've tried using a strong name and GAC to solve it, but it still refers to the dll in the bin folder. If there is no AjaxControlToolkit.dll in the bin folder, the application will simply fail to load the assembly.
If I use complete assembly information on my like this
<%#
Register
tagprefix="AjaxControlToolkit"
namespace="AjaxControlToolkit"
assembly="AjaxControlToolkit, Version=1.0.299.18064,
PublicKeyToken=12345678abcdefgh,
Culture=neutral"
%>
It gives me Compiler Error CS0433
Can someone help me on how to use multiple version of assembly in an application?
Well the link for Compiler Error CS0433 makes it pretty clear that the core issue is not with multiple versions of the assembly being referenced - but with namespace + typename conflicts.
When you load up / reference a type - the compiler can't resolve which DLL to load that type from. If Sharepoint is going to load both your DLLs versions (as you say it needs to) - this error will always come.
Simplest fix would be to change the namespaces in the new DLL, since it does have your custom tweaks, and you control the code - mark it clearly as well.