Method not found on runtime
I开发者_StackOverflow社区 have an ASP.Net c# project trying to access methods in a class in another project. It's working for first half of methods in the class but not for the other half of the methods in the class which I recently added. They compile, but they throw a method not found exception at run-time.
Does anyone have any ideas I could try? I've tried:
- recreating the
.sln
file - Subbing in another class library project, which I know works. It appears that the error is in my main project that calls the method in the other project.
"Method not found" is a very specific error, which means a method it expected (i.e. was there at compile time) simply is not present. This usually means that the files you are deploying are different to what you think they are - specifically, I would wager that you are deploying the old version of the library (which lacks your additions).
Check the dlls deployed to the web-server against what you think they should be.
I had the same issue. In my case, it was caused by the addition of an [optional argument][1]. So first you would have:
referencingAssembly:
referencedAssembly.DoStuff(firstArgument, secondArgument)
referencedAssembly:
public void DoStuff(string firstArgument, string secondArgument)
{
//stuff to do
}
Then you add an optional parameter to the method, but you don't provide that argument while calling it.
referencingAssembly:
referencedAssembly.DoStuff(firstArgument, secondArgument)//unchanged
referencedAssembly:
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument = "default value")
{
//stuff to do
}
Locally, this will build and run fine since the newly build referencingAssembly.dll will have a reference to the DoStuff(string, string, string) method. But when you only deploy the changed referencedAssembly (thinking: the added argument was optional, and the referencingAssembly still works), the old version of referencingAssembly will throw a MethodNotFound since it seeks a method with the signature DoStuff(string, string), which is no longer present in the referencedAssembly since we added the extra (optional) argument.
A possible solution could be an overload:
referencedAssembly:
public void DoStuff(string firstArgument, string secondArgument)//original method
{
DoStuff(firstArgument, secondArgument, "default value")
}
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument)//new overload of the method
{
//stuff to do
}
Or deploying the newly build referencingAssembly (which will refer to the method with signature DoStuff(string, string, string)). [1]: https://msdn.microsoft.com/en-us/library/dd264739.aspx
Two projects in your solution : project A and project B. Both projects use the nuget package "DoStuff", but different versions of the DoStuff package:
- project A references version 1.1 of DoStuff.
- project B references version 1.0 of DoStuff.
- project B references project A.
version 1.1 has a new method, that is used in project A. when project B uses project A, you'll get this MethodNotFoundException, because project B's version of DoStuff doesn't know what project A is talking about.
To prevent this, we have a unit test in place that fails if projects are using different versions of the same nuget package. A relatively simple doorstop that has saved us a couple of headaches in the past years.
I have faced this kind of problem but was able to solve it. I emptied my bin and debug folder and tried building the project again. it worked, at least for me. Or try to clean the solution and try rebuilding it. But of course, posting a part of your code could be more helpful.
had the same problem, in my case setting the optimizeCompilations to false in the webconfig solved the problem
I had a very similar problem and found that an older version of the assembly had been installed to the GAC. After I uninstalled that version, the project compiled and ran correctly. So check the GAC (C:\Windows\Assembly
) to be sure it's not listed there.
I encountered this same exception too, though my problem was different, I had a method in one of my library originally looking like this:
public void WriteMessage(string msg)
{
...
}
and there were some new request for modification and it turned into this:
public void WriteMessage(string msg, int code = 100)
{
...
}
after that, I updated the project that is using this library with newly compiled binary, it started to throw this exception.
After many attempts, nothing worked, even project clean, rebuild, removing and re-adding the reference, then I tried to modify the project's method call from:
...
library.WriteMessage('hello!');
...
to:
...
library.WriteMessage('hello!', 100);
...
and then compiled the project, it solved the problem, after that I changed it back to:
...
library.WriteMessage('hello!');
...
and now it magically fixed everything, maybe there were some kind of cached metadata left somewhere that isn't being updated, and by changing the way the method is called somehow clearly remind it that the method's signature is different, yet not so different.
Hope this can help someone facing the same problem that I experienced.
Look, this must be the weirdest cause ever, but after a whole morning trying everything, rebuilding the project from scratch, etc, I noticed that the single only thing that would avoid the problem was if my library had a different assembly name.
I had a ghastly suggestion from the back of my mind that I had installed previous dll versions in the GAC, but I already checked that and besides, it was never my intention. But following that trail I found out this dll (and all the others from the project !) where installed in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE !!!!!!
Aaaargh ! Guess I'm the only one that somehow messed this up, but I have no clue why, I just thought I could spare someone else this frustation in the remote possibility that someone is so unlucky !!
I encountered the same issue when i was running an application with nuget package managed dlls. It turns out when I try to update the dlls from nuget package manager, it did not update my test layer. I suggest you to check the version of dlls you are referring to. Go to ObjectBrower in VS and check on the dlls and check the referring location: make sure you are referring to the latest dlls.
My case was a little variation of the other ones here ; but it might help someone. I just added an optional argument in a library and got that message from the GUI using the library.
The problem was caused by the GUI and one of its libraries referencing the same library but one was not up to date.
I have
- GUI referencing LibA and LibZ
- LibA referencing LibZ
So I just removed all "bin" and "obj" folders of both LibA and GUI, made sure to have the updated DLL of LibZ in both, and everything worked again.
It may be a late response: But one possible remedy is to clean up Temporary ASP.NET files folder: I.e., C:\Windows\Microsoft.NET\Framework\vX.X.XXXXX\Temporary ASP.NET Files
Deleting the folders related to your website, and rebuild the solution.
If you were referencing another project as .exe
, you have to rebuild it as .dll
, to do that you have to set the referenced project to class library
into the project settings then build it and referencing the dll into the project were the method was missing.
Little late to the party.
Check the contents of the GAC.
If your .dll is already in there then you need to remove it.
Use the developer command prompt run as admin and type
gacutil -u {name of your dll}
I had the same problem, then I changed the method name to a different name, and changed the references . Then it worked great. I don't know what the problem was, but it looks like there is a bug when changing a method name in some circumstances, is not applied to the whole system.
I was faced with the same issue, I even cleaned and rebuilt the solution but it didn't help. When I published the application, the old version of the dll was in the bin folder. So I changed the assembly version in the assemblyinfo file. Finally it started working. The new version is available in bin folder.
I just had this issue:
Project X is a library used by other projects, it contains dll Y. Project A contains an older version of dll Y, and project A calls code in project X that is from dll Y.
The older version of the dll was used when calling code from that dll. Whereas other projects that did not have dll Y referenced, just used the up to date dll Y in project X.
Make sure you update the dll/nuget package in all projects that contain it.
The error also occurred when I had an Action as parameter. I passed a method without wrapping it in a new Action(..).
DLL had this:
public bool ShowMyForm(bool showConnectionWindow, Action onCloseNotify) {...}
Test app called the DLL like so:
private void onFormClose()
{
MessageBox.Show("Form Closed");
}
private void ShowForm()
{
mydll.ShowMyForm(true, onFormClose ); // bug here: wrap in Action
}
When I changed the call to
mydll.ShowMyForm(true, new Action(onFormClose) );
the exception disappeared. The exception text is just misleading - the method is there, but the type of the parameter gave a runtime exception. Too bad it is not picked up at compile time, though.
In my case I deployed to a .NET 3.0 PC (Windows XP) while the compile target has been .NET 3.5. I really wonder why there is not a more basic warning...
Problem has been usage of DataContract from System.Runtime.Serialisation.
I had this problem when I had copied the solution to a different location on another machine. The Build folder just needed to be changed. Don't ask me why but the solution was built in the build folder (we'll call this folder A) then an old copy was copied from folder B to folder C. At runtime it couldn't find my latest code because it was looking at an older version in folder C. In Properties for the solution in the Build tab, I changed the Output Path to folder B. It then built the latest version in folder B which it copied to folder C and it all worked again.
The bit I don't know is why we have folder C in the first place. I have a codedUI Testing solution and folder C is "C:\Users\\Documents\MyCodedUISolution\TestResults\_ 2017-04-20 11_31_29\Out". What this is used for and why it's created, I don't know but if old code is copied here because you change the Output Path or you move the solution without changing the Output Path to what's needed then you're in trouble.
In my case I had changed the return type of a method from IQueryable to IEnumerable.
I had recompiled and uploaded the DLL containing the method but not the DLL with code which calls the method. So the calling DLL was still expecting the method with the previous return type and couldn't find it.
I was not able to fix it with any of the suggested answers. I could not find any old versions of the custom assembly. I literally searched everywhere with the tool Everything. In debug mode it showed the right version of the assembly but it still could not find the method.
Enabling Automatic Binding in the .csproj
file fixed it for me
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
I was targeting a package of .NET Framework 4.5 in my project. The above setting is not needed if all packages in the project target .NET Framework 4.5.1 or higher.
In addition to Nirman's answer - don't forget clear temp files in C:\Users\UserName\AppData\Local\Temp\Temporary ASP.NET Files
location.
I changed class field type from enum to string and after that got error
System.MissingMethodException: Method not found: 'DatnesVeidi DatnesModel.get_DatnesVeids()'
when rendering Razor view. None of the previous suggestions helped, just clearing user local temp files.
For others visiting this question in future:
I had this problem testing a replacement netstandard2.0 library that was being integrated with another project. A few other projects within the ecosystem also depended on this replacement library.
When testing the new library in the system, the MissingMethodException
occured.
In my case, we had changed implementations of a base class's abstract method in the new library but we hadn't rebuild the projects that were dependent on the new library.
This must have caused the expected abstract implementation of the method to be missing at runtime.
It could help to ensure that all dependencies are being rebuilt.
I know this is a very old question but maybe this will help out somebody.
I had the exactly same issue. Fixing the problem was actually deleting all project files that I recently published from the web-server, cleaning and rebuilding the project and publishing it again.
After doing that I got the exception 'The file has not been pre-compiled and cannot be requested'. Turned out that I had a assembly missing.
The error message is definitely very misleading and it took me 3 days to fix that issue.
I'm posting the answer in the hope of helping someone that got stucked like I was.
I had the following error:
Method not found: 'Microsoft.Scripting.Hosting.ScriptEngine IronPython.Hosting.Python.CreateEngine()
I tried may on the suggested solution, including (but not limited to) using gacutil.exe /u IronPython
developer console ad admin, but nothing worked for me except the following:
1- Going to C:\Windows\Microsoft.NET\
2- Search for "IronPython"
3- Delete every folder I found, in my case was:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\IronPython
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\IronPython.stdlib
In my case I manually updated Nuget packages without updating their version numbers. The packages were loaded from my local cache, even if I completely reinstalled the packages, because the version numbers were not updated. Once I incremented the version numbers of my Nuget packages, the method could be found.
精彩评论