I have a solution which has a number of projects and each project refers to assemblies that are in a third party folder.
I now need to have access for debugging the code of those assemblies and fortunately I have to code.
I was wondering what the best way is to reference the code of the assemblies in my current solution?
Should I remove all my references to the assemblies (in third party folder) and then add the projects of those assemblies to my current solution or is there a better way? Although this gives me access to the code, the problem I see here is the assemblies were originally in a third party folder so I will need to make sure I have to switch back to the third party folder when I check my code back in.
There must be a better way than this?
You actually just need the corresponding pdb files of the third party DLLs.
The pdb file contains all necessary information. No need to remove the references.
It is not good idea to debug third party assemblies due to licensing restrictions. But if you want to do it, you only can remove references on dll's and add references to projects. You can automate your build to change references to dll's for release builds
You run your project while having reference to 3rdParty folder. Open those library code in seperate visual studio instance and use "attach to process" option in debug menu
Visit http://msdn.microsoft.com/en-us/library/c6wf8e4z(v=vs.100).aspx to know how to do this.
If you have the corresponding *.pdb file to the DLLs in question, you might getting away with just adding them to your solution. They need, of course, to be copied into the same location as their DLL files.
Related
I am getting this error:
Could not load file or assembly, system could not find the file specified.
Images:
http://s30.postimg.org/4x936f6ch/error2.png
http://s17.postimg.org/41ta9aaj3/errro3.png
I have a solution built in .NET 4.0
In it I have projects that act as plugins. They use dlls and the issue is that one of the solutions projects dlls is being called, and that references the dll that is causing the issue.
I get no error when rebuilding etc just when the program gets to the part where it uses the dll that references this one.
I have also made sure that in the projects bin folder that it has the dll that it is complaining about.
I have opened the dll in reflector and I don't think it has any issues.
COuld someone point me to the next step to try with fixing this issue?
Thanks!
Couple of tips - hard to know if they'll help you:
Open the csproj file(s) in a text editor and see where the dlls are being referenced (GAC possibly)
If it's a signed assembly, make sure you've got a signed copy (if you've built an Open Source project yourself the signing will be lost)
Look at the references in Visual Studio - do you have Copy Local set to True and Specific Version set to False?
Look at you're App.config or Web.config - is there a binding redirect that failing to load
I remember reading a post about assemblies not being able to be unloaded - probably not an issue on this one but I think the trick was
to load the DLL in a separate AppDomain to keep it isolated - loadable
and unloadable.
In my .net project I have 4 class libraries and a web project. Can you please guide me towards the correct way to add a reference of one class library to another class library?
In every project inside Bin there are two folders:
Debug
Release
I have tried selecting an assembly reference form Bin/Debug/, but every time I clear my project, all references are lost and I have to build projects one by one, which is a sort of pain. Also, it looks like when I build projects in Release mode these references will not work again.
My way of referring is probably not correct. Can you please guide me towards the best way to use references? Is there any way that I can be saved from these issues?
The bin and release folders are there for building the project, thus when cleaning the solution those will be deleted (usually).
We usually add a folder, and place referenced assemblies in this folder, the folder forms part of your main solution structure, so it may be checked into source control.
I am using Visual Studio 10 within a C# MVC appliction.
I have a qustion on a .dll reference. I am using a third party reference called
Ionic.Zip.dll. What I am not sure about is that it currently points to a location on my C: drive.
How and what is the best practice for me to put this .dll so that when I check in the project, others can also see this .dll without it blowing up.
Thanks
I would typically put a Library folder in my application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into your source control.
Now, anyone that pulls your source will have the required dll.
Even easier...simply add a reference to DotNetZip via NuGet, the Visual Studio Package Manager:
http://nuget.org/packages/DotNetZip
And you shouldn't have to worry about it.
The best way is to use Nuget.
But in some cases Nuget is not available or not getting compative, so as our friend says, its better put a Library folder in application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into source control. Now, anyone that pulls source will have the required dll.
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.
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).