I'm seeing the following error crop up occasionally (seemingly at random) on my web application. We are running Windows Server 2008R2, IIS 7.5, MVC3, .NET 4.5.
It's the same error every time: CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.BinaryOperation'
When this error occurs, it can take anything from a restart of the application pool, to the re-install of our application itself, to fix it.
The error occurs on brand-new VM images (no previous installation of our software), as well as machines that have previously had our software installed on it. The error can occur upon the first run of the application, or when the application has sat long enough for the IIS application pool to recycle the worker process (so it seems).
This is becoming really difficult to deal with, as I've done a ton of research on this error, and tried multiple solutions, with no luck. Also, the random frequency at which the error occurs has made it very hard to troubleshoot. Any insight into this issue, or ideas on possible solutions, would be greatly appreciated. I'm willing to try almost anything at this point.
This looks familiar. If I recall corectly I had to delete the bin directory and rebuild because older versions of dlls were floating around and this class was introduced in .net 4.0
After some research, this site seems to agree: http://our.umbraco.org/forum/using/ui-questions/20474-Missing-compiler-required-member-MicrosoftCSharpRuntimeBinderBinderInvokeMember
Try Forest Cheng Answer:
What version your .NET Framework is?
The ASP.NET MVC 3 run-time components require .NET Framework version 4 and Visual Studio 2010 or Visual Web Developer 2010 Express. Want more information, please look at ASP.NET MVC 3 Release Notes.
Compiler Error CS0656 can be caused by the follow problems:
Your installation of the common language runtime is corrupt.
You have a reference to an assembly that defines a type that is also found in the common language runtime. However, your assembly's type is not defined the way the C# compiler expects.
So check your references to ensure that you are using the correct version of the common language runtime.
We used to have these compilation errors occuring randomly back in the day a long time ago with .net 1 and beyond. This required deleting the contents of the temporary asp.net folder, and finding other rogue dlls that were hanging around, even inside a visual studio cache. In general, flushing the temporary asp.net folder will do it.
Make sure you find all the dlls - the bin folder too obviously, and remember that the dlls are executed from a shadow directory. That is why i recall (also from a long distant memory) that there is a connection to the default appdomain which assemblies are loaded into, especially if you then go loading "the same assembly " but from a different file location.
Make sure you have Microsoft.CSharp reference added in your project.
I added it to my test project and the error disappeared.
Related
We have a C# .NET website which was developed and maintained by a third party. I'm due to take over the general upkeep soon, so am trying to get a system going where I can maintain a local copy and deploy updates to the website. We need to make it work for two of us to work on for at least another month, after that I'm on my own.
We have an SVN of source, and an SVN of production published code. I can pull the solution and after some faffing I can make it build and run without problems locally. I'm using Visual Studio 2015, the target framework is 4.0.
I can update cshtml files, build, publish locally, and then copy these files over the website published version and it runs fine.
However, the bin/dlls that are produced, if copied into the website version, produces this fabulous error:
http://website.com/Error/InternalServerError?aspxerrorpath=/
Server Error in '/' Application. Runtime Error.
Description: An exception occurred while processing your request.
Additionally, another exception occurred while executing the custom error page for the first exception.
The request has been terminated.
If I copy back the dlls from the original, it works fine.
If I don't modify the code, but just build and publish the project, my dlls are still different sizes from the website versions.
The developers are using Visual Studio 2012, is this a factor? Why are the dlls for my local version (that runs fine) different, if I download the source and build/publish it with no changes?
The dlls in question by the way are a single one for the website itself, website.dll say, and one for 'objects' that they've dumped a load of functions into for doing various things, objects.dll, these are the only two I'm trying to copy over - all the other dlls match in size between my and the website versions.
I'm pretty new to this so may be making some fundamental mistakes here, but if I am, then our developer isn't picking up on them. I mean, I'm kind of not surprised that they're different, surely you need to deploy the whole project, and not just drop some dlls into an existing published folder? My developer is saying that's the only way we can do it...
Any tips of things I can try?
Thanks in advance.
Well, after a LOT of trial and error, I finally found a solution that works for me, for the moment:
Using nuget package manager, I reverted to Microsoft.AspNet.Mvc version 4.0.40804 for the project in question. This seems to have updated all the references and runtimes back to the 4.0.0.0 that the project was built using.
When I build, publish, and copy across the main dlls, the site now runs, rather than showing the 'Server Error in '/' Application. Runtime Error'
One thing, are there security implications for running such an old version? Maybe that needs to be a new question...
Thanks for all the help.
I have a solution with several projects in it, one of them being a website. The website has references to five web services, which are being run on our own servers. When building the website with VS 2010 I get the following error:
Validating Web Site
App_WebReferences/VpService/(1): Build (web): Reference.svcmap: Could not load file or assembly "Konzeptum.BL.Base, Version=2.6.0.0, Culture=neutral, PublicKeyToken=null" or one of it's dependencies. The system cannot find the file specified.
The service that produces this error changes on every build. The apparently missing dll cannot be found on any of the machines I looked at, it's not even present on the servers running the services. The services however have references to some APIs which in turn have references to the dlls Konzeptum.BL.Telerate.Provisioning, Konzeptum.VO.Base, Konzeptum.VO.Telerate.Provisioning. My guess is that these dlls make use of the missing Konzeptum.BL.Base.
I can compile each project just fine (the services, APIs etc.) just the website has this problem. I have tried updating the service references, deleting and re-adding them, nothing. The only solution I could find online (and that kind of works) is deactivating the reuse of types in the Service Reference Settings for each service. I uncheck the three dlls mentioned above and reuse all other types.
Now however if I build the website I get errors that there are ambiguous references between types provided by the service and existing ones (e.g. FileInfo from System.IO) or errors that some data types cannot be found. These missing types however have nothing to do with Konzeptum stuff, they are defined by the services themselves. Luckily for me these errors pop up very late in the build process of the website, so that most of it is usable.
What could be the cause of these problems and how can I solve them?
Thank you for any help.
Edit:
Maybe it wasn't clear before, but this problem seems to occur only on my machine, two other developers don't have any problems building the website (and we're using the same tfs repository). The servers running the live system don't have any problems. But the missing dll is not present anywhere, so I can't just copy it over. The Assembly Binding Log Viewer isn't of much help either, in the entry for Konzeptum.BL.Base under Calling assembly it just says (Unknown).
Ok, after searching for differences between my machine and those of the other developers I found one that I thought shouldn't matter at all. They had .NET version 4.0 installed vs. version 4.5.1 on my PC. So after uninstalling 4.5.1 and installing 4.0 the problem went away. I can now successfully compile the whole solution without any errors. Why that is - I have no idea. The projects in the solution all target 4.0, so I thought running them under 4.5.1 should be no problem, but I guess not. I even went through the list of changes between 4.0 and 4.5/4.5.1, but I couldn't find anything that relates to my problem.
Thanks to anyone that tried to help.
During our adventures of building a 'simple' API using WebAPI we've had our fair share of issues as any project does, however I am unable to find any such resource that can explain the following behavior:
Details :
Visual Studio 2013 with Update 2 (however, before updating, this was the same)
Windows Server 2008 R2
Web API 5.1.2
The issue seems to be related to the "Publish" command, specifically the "Precompile" option.
When running via IIS Express, we see no issues at all.
If we publish once, it fails to include the App_Global.asax.compiled & App_Global.asax.dll in the bin directory. If it is updating an existing instance of the application, it will actually delete the existing two files.
Note: This Happens regardless of WebPublish or FileSystem Publish
This behavior is causing 404.0 Errors upon loading to IIS, instead of our expected 201.
However, if I publish a second time no changes to the previous profile/configuration, it adds the two back.
For a while, we thought it was permissions issues, and weren't seeing consistent behavior. This happens on all of our development machines with the same behavior.
We've seen posts regarding mysterious behavior, but from our analysis, this is the root of the problem.
Just wanted to let everyone know that my problem was solved.
This was an issue with a virus scanner scanning the newly created temp directory for precompiling and actually locking the files in question.
So if anyone has issues such as this and is running any antivirus (especially enterprise level):
TLDR:
Check if your antivirus is locking files.
Turn off all compsec scanning utilities and turn on one by one to isolate which is causing problems.
I am helping out with a project that a contractor worked on previously (so I don't have a lot of history for it).
The project builds fine, but when we try to perform some operations, we get a runtime error indicating that System.Management.Automation.dll could not be found.
As a troublshooting measure, we manually installed the dll into the installation directory. We then get an error indicating failure to load Microsoft.Management.Infrastructure.
As nearly as I can tell, these dlls are present in the Microsoft Management Framework download, and possibly in Powershell 3.0.
My question: What is the smallest package that these dlls are a part of, and what is the best way to deploy them for a production software release?
Edit
Just to be clear -- I am not looking to hack/frankenbuild by deploying just those dlls "naked", I am trying to identify the correct redistributable package for those dlls. I just can't seem to work out which one it is.
Edit
If it helps, the nature of the code that we are running is to programmatically create an exchange mailbox.
I think you can't legally redistribute any of those two DLLs alone (discussed for example here for the Automation, you can also check the "Redistributable" section on MSDN for those namespaces). You will have to make sure the target machines have PowerShell and the Management Framework.
Just in case anyone else runs into this problem: We ended up resolving the issue by deploying the Windows Management Framework 3.0, which includes the necessary assemblies. http://www.microsoft.com/en-us/download/details.aspx?id=34595
I have an InvalidProgram exception with the message
Common Language Runtime Detected an Invalid Program
This happen in an application that we didn't change in the last 3 month.
The only change is that we have change our build server (reinstall it).
The server is running Windows 8 and has Windows SDK 7.1 on it.
We package the application with ClickOnce.
This exception happen in a very specific method call, after methods of the same class as assembly are already called, so I think it rules out assembly loading issues.
I can't find a lead to where to start debug this issue. I think it related to the version of the tools I use on the build server such as MSBuild, CSC, mage.exe and such.
I found people say this error might happen when I have very long method names, but this does not seem to apply here because I don't have long methods names and I don't generate code myself.
The application use .NET 4.0
Update 1
It is for sure a problem with the compile tools (the version I think) or the ClickOnce packaging tools because when I compile and run the application on my machine it work, when I install the packaged application on my machine it show the exception above.
add this argument to your compiler: /nowin32manifest