I have a referenced assembly that keeps failing when I call it. I have the source for this assembly in a large project, Project A. I've compiled it and have been using it in Project B. Unfortunately Project B keeps failing and the stack trace shows that it fails on Project A's assembly.
It seems like I have two options:
Add Project A to Project B, change all references to the assembly to the project. This seems like it'd be a lot of work.
Use some third party tool, like Reflector, to step through the assembly.
Is there any other way I'm missing it? Is there anyway to link the projects easily?
Sorry if this sounds naive. it is the first time I've run into it.
if you have source code of project A
just include PDB file and assign referecne of the project A dll.
when you reach method of prject A press f11 which will take you to project A.
Add ProjectA.pdb to the folder that you're referencing the DLL from and Visual Studio should pick up the debugging symbols and step in automatically.
Related
We have an app A that has a reference to an assembly B that contains some static methods. Assembly B is in the same Visual Studio solution as app A.
We want the users of our app A to be able to write plugins. They build the plugin (at present) by creating a new Class Library solution in Visual Studio, getting the Nuget Package for app A, and adding a reference in their plugin solution to assembly B, so that the plugin code compiles.
They do not need to test their plugin, which is why the code just needs to compile, although it would be nice if they could debug their code when running it in app A.
Once their code has compiled, the DLL for the plugin is put in a share and given to a different team (bureaucracy I know) who put it with the rest of app A's DLLs.
I would like the plugin DLL to use the assembly B DLL that is with all of app A's DLLs.
When I run app A, the Activator class picks up the plugin DLL and correctly creates an instance, but as soon as one of the static methods from assembly B is called, the plugin throws a MissingMethodException.
Things I have tried:
The plugin solution definitely works fine if you create it and compile it within application A's Visual Studio solution.
App A uses framework .Net 4.5, assembly B uses framework .Net 4.0, I have tried building the plugin with both frameworks without success.
The "Specific Version" of the reference to assembly B in the plugin solution was false in all cases tested.
I would welcome immediate solutions to this problem but also broader architectural suggestions on how to get these plugins to work. I apologise if there is a duplicate question of this, I couldn't find one.
For starters you can use "Dotpeek" to decompile dll and see if the method defination exactly matches.
It's a free software available to decompile dotnet libraries.
If you don't have access to .pdb file then i would recommend using "dotnet reflector",or "IL Spy" it will decompile without pdb files.
Also do make sure you are referencing project in visual studio not the output dll.
I managed to fix my problem as follows:
Although the plugin only directly used static methods in Assembly B, these static methods actually made a chain of calls to various OTHER assemblies.
Instead of just adding a reference to Assembly B in my plugin, I did a Nuget command:
Install-Package -Id AppA -ProjectName Plugin
And this downloaded the latest AppA to the packages folder and added a reference to EVERY dll of AppA.
Like before, it compiled, but this time when I dragged the plugin dll into the AppA bin folder, the plugin code ran without throwing an exception.
I have two C# projects, A and B, in VisualStudio 2010. Project A is a class library. Project B is a ReSharper-Plugin project that references project A (ProjectReference). Both projects compile and worked property when I ran project A in the Experimental Instance.
Now, recently I renamed a static class, with some extension methods, in project A. Both projects still compile. But when I run project B I get an TypeLoadException for the new class name. When I change the class's name back, everything works fine again.
My guess is that project B is compiled against the new code, but run against an outdated dll. I tried everything from clear, over rebuild, to restart, but to no avail. I also manually checked that a fresh dll from project A is placed in project B's bin/Debug folder, which is the case. And I copied over the dll manually, after building project A. The problem persists.
Now I ask myself whether there is another location where the dlls are copied to before running the Experimental Instance. Is this the case? If so, where to? Are there any other places where the old version could come form? Or is there even something completely different that could cause the problem?
Thanks in advance!
Ok. Did you reference the DLL or the Project? In a Visual Studio Solution you can reference projects. If you reference project A in project B then B should always use the latest code from project A.
I managed to figure it out myself, thanks to the right keywords on Google (MissingMethodException and ProjectReference) that led me to a blogpost about a solution to the same symptom. In my case it was not the GAC that caused the problem, but the cached assemblies under
C:\Users\{name}\AppData\Local\Microsoft\VisualStudio\10.0Exp\
This is the location where all the assemblies of the Experimental Instance go. Here lay an outdated VsExtension that depended on project A and within it there was an outdated copy of project A that was loaded. The loading of the new version from the project reference was simply skipped, since a copy of the assembly (with the same version) was already loaded.
So the problem was ultimately caused by the removal of the extension from my solution. From this point of the extension was no longer updated by VS, but it was also not removed! Lessons learned: After major changes of your infrastructure you may want to delete all cached assemblies below the above path...
Thanks for the help, everyone!
I have a project (call it A, it's an exe) which references another project (call it B, it's a class library) which references a dll (call it C). When debugging A.exe from visual studio I get a run time error:
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in B.dll. Additional information: Could not load file or assembly 'C', Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
When I go to my executing bin\debug directory, sure enough, C.dll isn't there.
I've explicitly called classes in C.dll from B.dll, so there isn't any weird run time adding of references or reflection being used to call it. I've also set "Copy Local" to true on C.dll. If I reference C.dll from A.exe directly, then it runs with no problem, but I'd rather not have to do that.
I've tried to repro the problem in a new solution, but I've been unable to.
Does anyone know what might be preventing this dll from copying to the final output directory?
The best thing you can do is have the projects A, B, and C all in one Visual Studio Solution, then you can reference the other projects that you need without referencing the dlls.
Once you have that, then add a Project Reference like this:
project B references project C
project A references project B
Because you are then referencing the projects, it will pull the necessary dlls along for the ride when you compile the whole thing.
However, as neo said, if you keep C as a dll, then A will have to reference it as well, because VS is not smart enough to copy it as well.
I've encountered similar problems so I'd recommend to try these things:
Toggle "copy local" to "false" and then to "true" again, it should resolve the problem, if the problem is missing
< Private > True < /Private > node in project file
Check Target Framework of your project, I'have similar problem with several projects targeted "4.0 framework" and other "4.0 client profile", after switching to "4.0" on every project was resolved
Ok finally got it...I think.
It looks like the C project didn't have any version information under Application-->Assembly Information. It was also missing a guid.
For the record: You CAN reference the way I described (A refs B which refs C) and have the output copied. I did go back to a dll reference rather than a project reference and it still worked after a clean and build.
I'm still not sure why I was able to get this to work in a new solution (before making changes), but I'm up and running now.
Edit:
One other note, it looks like there was no assembly.cs in the project (which is why it didn't have any version info). I wonder if it was just a recompile of this project that could have fixed it rather than updating the assembly info.
While doing some refactoring of our projects and solution files, i have separated some .sln files to contain less projects.
Occasionally i need to reference some projects from outside the scope of the current .sln file.
For example, my initial state was this:
SOLUTION A
PROJ A
PROJ B
After refactoring it would look like this:
SOLUTION A_NEW
PROJ A
SOLUTION B_NEW
PROJ B
My question is -- Is it possible to add a ProjectReference node to a project that is not defined in the same VS solution? (in my case, having PROJ A have a project reference to PROJ B).
Also, if it is possible, is that recommended?
I know that this is not possible from the VS IDE, only by editing the .csproj file manually.
You can't do this. A project reference includes an identifying GUID for the referenced project, which is maintained in the solution file in order to track solution build options and dependencies. If you try to reference a project that is not in the solution, Visual Studio will complain.
You can add a file reference to the assembly produced by a project that's not in the solution, of course.
UPDATE: Since this got downvoted, I'll refine my answer.
Though it's technically possible to craft a project file that references another project outside the same solution, Visual Studio won't help you to do it easily. One very good reason why it's a bad idea to do this (that I've observed) is that whatever Solution Configuration and Platform you're building (the referencing project) will be ignored if MSBuild decides to build the referenced project - the default Configuration and Platform specified in that referenced project file will be used instead. Thus you may end up with a mixture of binary types in different folders.
Temporarily add the project to the solution, add a reference to it, unload the project that now has a reference added to it, remove the referenced project, reload the project with the reference.
If you don't unload the project then the reference will be automatically removed by Visual Studio when the referenced project is removed.
As you can probably tell, Visual Studios not designed to do this and you'd be better defining a build order for the solutions and use assembly references instead.
You can definitely add a project to a solution A that is in solution B. There is not any problem with that. From my experience, it's not something that I usually have done or do, but sometimes need to. This can be especially true on large projects where you need different nodes of your architecture to reuse same code base.
Hope this helps.
Has anyone experienced this or found a solution? I have tried the following:
Referencing the output dll directly without moving it
Uninstalling the output dll from the GAC
Neither option made a difference. Please note that the generated XML doc has the same name as the dll and is included with it.
Ah ha. I found the reason why this was occurring.
If you referencing your ILMerge project within Visual Studio (i.e. as Add Reference -> Project) then Intellisense will not use the generated XML doc.
To solve: In your post-build step copy your output files to a common directory (e.g. Reference Assemblies) and then link against the DLLs. You can still have the project in the solution, however you must setup the project dependencies so that it will build if you have made changes.
HTH,