I have a problem with getting above exception. I have a relatively simple structure separate in two dll.
First one contains a IEntityService, IEntity, with basic implementation. Second one contains the actual implementations as well as interfaces. so there is a IMachine service which implements IEntityService and MachineService which implements both IEntityService and EntityService. Similar situation happen for a Result collection( entity plus service). Additionally the service(Machine and result) are partial classes/interfaces where one of the class is auto generated.
Now in one of the ResultMachine I am trying to get a machine and in a case it do not exists I am creating it and saving. However when I am trying to save I got the "Method not found" when trying to access a saving method from a EntityService class. However if I wrap EntityService.Save method in a MachineService it is working without any exception.
Edited:
The code is not required. THe resolution was to re-link the reference. What was misleading for me that my dll is not in GAC, it is linked with VS. What is more it is not strongly signed, the only difference is version number.
We have got this error a few times, you can recreate the problem as follows:
Created project with 2 dll's (say a program dll and a test dll)
deploy program dll to GAC
Add new method
Create test to test the new method
build solution
run test (not in debug mode)
You will now get the method missing exception. The reason is that it is using the old version of the dll that is in GAC and does not have the method.
Some times it uses a cached version of the old dll, IISreset can help.
In your case check for any old versions of the dll.
My first instinct would be to check to make sure the assemblies contained the classes with the missing method. I suppose its possible that the assembly didn't get updated immediately?
When referencing the "same" type from different assemblies, make sure you are loading everything via the same path. Otherwise, identical types can actually be treated as if they are different.
See this article for more: Fusion Loader Contexts - Unable to cast object of type 'Whatever' to type 'Whatever'
This happened to me when I went in and tweaked my build settings to output to /bin/Debug rather than to just /bin in a case when I was also using IIS to host the site from the dev folder.
You need to have the binaries in the same folder as the service, in my case, and the tweak left old versions in the bin folder and put subsequent builds into the /bin/Debug folder (and /bin/Release).
Either keep the settings as is and have a post build action to copy the bits up one level, have different IIS applications for debug/release, or deploy to another folder altogether. The latter is probably most "correct" but for my purposes I just realized after much wheel-spinning, that I had different versions in the service's folder. HTH.
In my case I just deployed on a machine with .NET 3.0 (Windows XP) while the compile target has been .NET 3.5.
This error message is really not helpful.
Problem has been usage of DataContract from System.Runtime.Serialisation.
Related
System.MissingMethodException: Method not found:
'System.Collections.Generic.List`1<!!0>
BusinessEntities.Helper.Sort(System.Func`2<!!0,!!0>)'
I get this error on a page in the website.The website build is prepared using visual studio web deployment project. When I deploy the build in IIS and run the page, I get the above error. When the website is run in debug mode in visual studio, it executes fine.
Background :
I have a asp.net 4.0 website which references the BusinessEntities project, which is a .NET 3.5 class library project. The project contains a public static Helper class which has the extension method Sort for sorting generic lists of objects. The Helper class is in the BusinessEntities namespace.
If I change the version of the BusinessEntites project to .Net 4.0 and then build the website, this error does not arise. The project cannot be upgraded to 4.0 due to some operational restrictions.
The strange thing in all this is that the generic extension method and the website and project structure has been in the solution since over a year without any issues. I am at a loss to understand why this error pops up all of a sudden.
A MissingMethodException means that you are loading a different version of the dll than the one you referenced during your build, and the actual dll you are loading (at run-time) doesn't have the method the compiler found (at compile-time).
Check that you haven't somehow got different versions of the same dll referenced in your project. It might be that when you run it in debug mode, some other code makes the correct dll load first, but when running in release a different dll gets loaded due to reference mismatch, or you might have multiple versions of it somewhere.
I was facing same issue ,I have fixed using below steps...
1. Clean you solution
2. manually clean bin folder
3. delete temp folder
4. rebuild solution.
I have a Visual Studio 2010 C# project which creates an .exe and this project is using some 3rd party class library.
My project is located in: /MyFramWork/tests/test1
3rd party library is located at: /MyFrameWork/bin/utils/
I am adding the reference to the library by using References->Add Reference->Browse. I can see that in the project file all is fine:
....\bin\utils\log4net.dll
False
I would like to reference the 3rd party library without using the option "Copy Local". However if I don't use the option, the library is not found and I get an exception.
My question is: Is there a way to specify that the 3rd party library should be found at ....\bin\utils. It seems that when the .exe gets build the information from the .csproj gets lost.
By default, .NET apps look for their dependencies in only two places: the EXE directory, and the GAC (Global Assembly Cache).
You have three choices:
You can make sure the dependency gets copied into the same directory as your EXE (this is what Copy Local does). This is the best choice most of the time, which is why it's the default when you reference an assembly that's not already in the GAC.
You can install your dependency into the GAC using gacutil. This might be a good choice if your dependency isn't going to change, is going to be in a different location on every development machine (i.e. if relative paths won't work well), and if you want to use it from many different projects. But it's a major pain if the dependency is still under active development and changing frequently. You'll also need to make sure to put the DLL into the GAC on every computer you deploy your app to.
You can customize the dependency-loading behavior so it looks in other places, as Hans noted in his comment. This is an advanced option and comes with a whole new set of headaches.
Normally, you would just use Copy Local; it's a very sensible default. You should need a fairly compelling reason to do anything different.
Use the <probing> element to specify where the CLR should search for your assemblies. The only restriction is that the assemblies must be located in subdirectories of your application's base directory.
For example, if your application base directory is C:\MyFramework, then you could have your assemblies in C:\MyFramework\bin.
Have a look at this article to learn how the CLR searches for assemblies.
If you need to load assemblies from custom locations, you could try the Assembly.LoadFile Method.
The following links may be useful:
C# - Correct Way to Load Assembly, Find Class and Call Run() Method
http://www.csharp-examples.net/reflection-examples/
It's me Potzon. I am still investigating this incredibly silly problem.
I have been hoping for some elegant solution. I am about to build fairly large framework with lots of assemblies which would be placed inside /Framework/bin/. However I wanted to have some directory structure inside the the directory, for example /bin/utils, /bin/test, /bin/devices/ and so on.
One possible solution that I have found is to define environmental variable DEVPATH (see here http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx) but it turns out that .net4 is not using this variable when an assembly is run independently (outside the visual studio), or at least this is the case for me - I can't make it work.
It seems that the solution to put all the assemblies inside the /bin directory without using sub-directories is the best. I think I will give up and just do it this way.
Situation
I run a build system that executes many builds for many project. To avoid one build impacting another we lock down the build user to only its workspace. Builds run as a non privileged users who only have write ability to the workspace.
Challenge
During our new build we need to use a legacy 3rdparty DLL that exposes its interface through COM. The dev team wants to register the build(regsrv32.exe) but our build security regime blocks this activity. If we relax the regime then the 3rdparty DLL will impact other builds and if I have two build which need two different versions I may have the wrong build compile against the wrong version (a very real possibility).
Question
Are there any other options besides registration to handle legacy DLLs which expose their interface via COM?
Thanks for the help
Peter
For my original answer to a similar question see: TFS Build server and COM references - does this work?
A good way to compile .NET code that references COM components without the COM components being registered on the build server is to use the COMFileReference reference item in your project/build files instead of COMReference. A COMFileReference item looks like this:
<ItemGroup>
<COMFileReference Include="MyComLibrary.dll">
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMFileReference>
</ItemGroup>
Since Visual Studio provides no designer support for COMFileReference, you must edit the project/build file by hand.
During a build, MSBuild extracts the type library information from the COM DLL and creates an interop assembly that can be either standalone or embedded in the calling .NET assembly.
Each COMFileReference item can also have a WrapperTool attribute but the default seemed to work for me just fine. The EmbedInteropTypes attribute is not documented as being applicable to COMFileReference, but it seems to work as intended.
See https://learn.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference for a little more detail. This MSBuild item has been available since .NET 3.5.
It's a shame that no-one seems to know anything about this technique, which to me seems simpler than the alternatives. It's actually not surprising since I could only find just the one above reference to it on-line. I myself discovered this technique by digging into MSBuild's Microsoft.Common.targets file.
There's a walkthrough on registration-free COM here:
http://msdn.microsoft.com/en-us/library/ms973913.aspx
And excruciating detail here:
http://msdn.microsoft.com/en-us/library/aa376414
(the root of that document is actually here: http://msdn.microsoft.com/en-us/library/dd408052 )
Also, for building in general, you should be able to use Tlbimp or tlbexp to create a TLB file that you can use for building, assuming the point of registering is just to be able to compile successfully, and not to run specific tests.
Installation tools such as Installshield can extract the COM interfaces from the DLLs and add them to the registry. It can also use the self-registration process of the DLL (which I believe is what regsvr does), but this is not a Microsoft installer best practice.
in .NET COM is normally done thru Interop in order to register .DLL in .NET they are called Assemblies and that can be done several ways.. by adding references via VS IDE at the project level, or writing code that Loads and unloads the assembly.. by .Config file that haas the reference to the assembly as well as the using of that reference within the project... GAC.
If you have access to the 3rd party .DLL's you can GAC them, and reference them in your project
you can add a using to your .cs file header as well as add the reference to the project by right clicking on reference --> add Reference ...
you can also do the above step as well as set the copy local = true in the properties for that .dll.. I hope that this gives you some ideas.. keep in mind that .NET assemblies are Managed code so there are several ways to Consume those 3rd party .DLL's using other methods within C# like LoadFromAssembly ect..
Thanks for all the help.
We changed from early-binding to late-binding because we never really needed the DLL at compile time. This pushed the registration requirement from the build server to the integration test server (where we execute the installer which handles the registration). We try to keep the build system pristine and have easy-to-reset integration systems.
Thanks again
Peter
I ran into a weird issue today while debugging one of my projects. I use VS2010 / windows 7 home premium.
I have a project that uses Windows Server AppFabric Cache. I have configured everything, and have created two different C# projects (2 solutions) to test the AppFabric configuration. The project names are "AppFabricServer" and "AppFabricClient". This is just for testing and the naming convention doesn't mean anything specific. I use "AppFabricServer" to Add objects to AppFabric Cache and "AppFabricClient" project to retrieve.
Now, the problem is after running the "AppFabricServer" and then I try to run "AppFabricClient" after closing the "AppFabricServer", I get an error "System.IO.FileNotFoundException: Could not load file or assembly 'AppFabricServer". I don't understand in which way "AppFabricServer" project is related to "AppFabricClient" project.
The same thing happens vice-verse also - this means, after restarting the computer and if I run "AppFabricClient" project first (it also has a Cache writing module), I am not able to run "AppFabricServer" project (it has a Cache reading module as well). I get the same error -"System.IO.FileNotFoundException: Could not load file or assembly 'AppFabricClient".
The exception is thrown at the line where I try to retrieve data from the Cache - when I call the Get method of DataCache.
Can someone please help?
AppFabric utilizes the NetDataContractSerializer to serialize objects. This serializer encodes CLR type information. So, even if the shape of your objects is the same, it actually requires them to be the same types in the same assembly.
Therefore, take the object you are serializing out of the AppFabricServer assembly and put it in a third assembly that is referenced from both the AppFabricServer and AppFabricClient programs. That way, the CLR type information will be the same in both.
I have library code that uses ICSharpCode.SharpZipLib under the hood to make it easy to use ZIP files as data sources when running integration tests.
As it stands, if I reference my library from another project, the other project will compile just fine, but when it accesses the code that uses SharpZipLib, I get an exception for it not finding the zip library:
failed: System.IO.FileNotFoundException : Could not load file or assembly 'ICSharpCode.SharpZipLib, Version=0.85.5.452, Culture=neutral, PublicKeyToken=1b03e6acf1164f73' or one of its dependencies. The system cannot find the file specified.
If the types in my library derived from a class in SharpZipLib, it'd generate a compile error CS0012. What other ways are there for triggering a CS0012, so that using code that requires SharpZipLib (but doesn't clearly indicate it) would cause consumer code to fail compilation?
I've had similar problems in the past when I've used libraries like DeftTech.DuckTyping under the hood. I'd add my library code to a new project, start working, compile, run, and then suddenly hit an edge case that I'd used duck typing to get around and get a runtime error.
What I'd most like is to have the same behavior as if I'd derived from a type in the 3rd-party library, so that a reference to my derived type generates a CS0012:
The type 'type' is defined in an assembly that is not referenced. You must add a reference to assembly 'assembly'.
You only get compiler errors if you are DIRECTLY interacting with libraries that aren't referenced.
If you use other libraries that internally use a third party library then you will never get a compiler error. The reason is this just doesn't make much sense having a compile error because:
It does not affect compiling at all, so why a compiler error?
Your application MIGHT run correctly, because there is no guarantee the third-party library EVER gets called.
It might actually break several libraries, that e.g. do reference external libraries for debugging, but just don't ship them for release.
Edit: If your problem is that you are forgetting about the third-party library you can simply reference it directly from your application even if you never use it. Then e.g. Visual Studio will automatically copy it to your output bin folder and includes it in setups, and so on.
If you're seeing this while in Visual Studio it's probably because the ICSharpCode.SharpZipLib.dll isn't being copied to the build folder of your "other" project.
So this won't be a problem when you distribute your library for consumption by third parties because the ICSharpCode.SharpZibLib.dll will be in the same folder as your library.
During development and testing though it can be a bit of a hassle. Generally when setting up a multi-project solution I just have all the projects target their Output folder to a single solution-wide Build folder. That way all the dependencies are copied to the same location for testing.
You just have to copy ICSharpCodeSharpZipLib.dll to C:\Windows\assembly and your problem will be solved.