I have a behaviour when importing a C# dll into another C# solution.
The dll I'm trying to import is a class library that I've previously implemented for another project and in which I made some improvements during time.
The dll compiles just fine and after I've imported it into the new solution the classes and methods are found by intellisense.
The problem is when I run the project in which the dll is imported and a TypeLoadException is throw (the message is something like "Unable to load type 'xyz' from assembly ...".
I've already tried to delete the .vs folder and clean and rebuild the solution (both).
I have also tried to decompile the actual dll to seeif there is something strange, but the classes and methods are actually there.
Thanks all.
I was importing the same dll on 2 different projects of the new solution and (I still don't know why) one project had an old reference to the dll (even if the reference was directly to the file).
Even if the method existed in the new reference, visual studio was loading the old one.
Removing the old reference and adding it again solved the problem.
Related
Problem
I have a static (extension method) that is referenced in my VSIX project. When I compile the VSIX project, I can see the dll in the bin/debug folder along with the VSIX dll (Same folder).
In addition, intellisense has no problems with this nor does the compile! When I run the VSIX project in debug mode. I see this error:
"Method not found: "System.String MethodName(System.String)" which is the extension method in another assembly (in the bin/debug folder).
I've read other posts like these:
Can't find VSIX dlls with DllImport
Include external .dll in Visual Studio Extension
Both solutions don't look right to me, after all, the dll is in the proper folder, it finds its own code, but not the other assembly.... The references and using statements and intellisense work!
This tells me that it's a loader issue, somehow VSIX projects are failing to load other referenced assemblies or maybe it's by design.
I've tried loading them as Assets but they are not "other" VSIX projects so all of the asset options are out.
Notice however that these asset types are all prefixed with Microsoft.VisualStudio. I've tried Microsoft.VisualStudio.Assembly and they do not work, in fact it screws up the manifest attempting to do that.
Another oddity, I did include a reference to yet another assembly that comes in as an EXE. All of those methods work fine. It's just the dlls that are not getting loaded. For these, I cannot use a USING statement rather, I have to use the fully qualifed NameSpace name to get it to work... But if I try the same trick on the DLLs it doesn't work.
One post suggested adding the assemblies manually to the manifest file... but that post was in 2010.
This doesn't work either:
To include satellite DLLs from referenced assemblies in the VSIX package, add SatelliteDllsProjectOutputGroup to the Output Groups Included in VSIX property.
What am I missing?
The root cause of this problem is that by default VSIX want's everything to be Strong Named. I had unchecked that option due to 3rd party DLLs which were not signed. I was able to get the source and "Strong Name" them.
I then strong named the VSIX project and everything worked.
Go to properties page of the project:
I began looking into tools like this, which can strong name DLLs when the source code is unobtainable.
https://brutaldev.com/post/net-assembly-strong-name-signer
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've got a project (project A)in vs2010 (c#) that I want to reference another project (.exe) (project B) that I created. Project A is a quick, down & dirty util that I will only use once but I need all the function calls and db calls from project B, so rather than cut, copy, pasting from one to another, I thought I could just reference project B in my references. I am able to point to the .exe and in code i can use it, but when I compile it, it complains about not being able to see it (the infamous "are you missing a using directive or assembly reference?" error).
Does anyone know how I can do this?
Most probably, also it's hard to say, you have .NET Framework version conflict. One of your projects has .NET Framework version which is not compatible with other.
Check in project properties of both of them the version of the framework.
Make them the same
Recompile both of them
and most probably the trouble will gone.
Hope this helps.
Make sure the namespace of classes you want to use from project A is included in the files in your project B in a using directive:
using projA.ExampleNamespace;
I have the same problem. When I first added the reference all worked fine. But some time later after a rebuild there were errors and the classes and namespaces of "project A" were not longer recognized. Removing and re-adding the reference solved the problem immediately (without rebuiling or anything). There were no errors in other code and all DLLs and EXEs were build correctly. Build Order and Build Dependency settings were also correct. Seems to be a strange bug in Visual Studio (I use 2013 Professional).
I also checked how the reference was set in csproj file. The csproj file didn't change at all after removing and re-adding the reference. Neither did the sln file.
Maybe it's some strange caching behavior. But as I used "Rebuild All" which cleans up temporary files imho, this shouldn't happen. Even restarting VS or the PC didn't help.
I've downloaded and compiled Amazon's .NET SDK for Mechanical Turk, producing two DLLs: Amazon.WebServices.MechanicalTurk.dll and Amazon.WebServices.MechanicalTurk.Domain.dll .
I then created a new WPF project and added the two DLLs as references. When I create objects from their space, Intellisense has no trouble browsing the assemblies- I can see the classes inside.
When I compile, however, I get an "type not found" error from the compiler. Intellisense no longer works for the Amazon namespace, and the DLLs have vanished from the Object Browser window inside Visual Studio, though they're still listed as references in Solution Explorer.
What's going on? I think I'm missing something obvious. I can see, for example, MTConfig, but when I try to instantiate it, it fails and I need to re-add the DLLs to try again.
Thanks!
How have you added the references? Did you copy the DLLs into your new project's output folder and add references to them there? I can imagine that giving the behaviour you describe, if VS wipes the output folder before a build. If that's what's happening, simply move the DLLs to a different directory (I typically create a "lib" directory) and point the reference there.
What I did to solve this same problem was to recompile the DLLs changing the .NET version from 2.0 to 4.0 in the project properties. Not sure why that works, but in my case it solved the issue.
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.