I've found the solution. I've recently upgraded my machine to Windows 2008 Server 64-bit. The SqlServer.Replication namespace was written for 32-bit platforms. All I needed to do to get it running again was to set the Target Platform in the Project Build Properties to X86.
We recently had the issue when trying to run the code from Visual Studio. In that case you need to do
TOOLS > OPTIONS > Projects and Solutions > WEB PROJECTS and check the "Use the 64 bit version of IIS Express for web sites and projects".
In an ASP.NET MVC 3 app I'm working on, I tried adding a reference to Microsoft.SqlServer.BatchParser to a project to resolve a problem where it was missing on a deployment server. (Our app uses SMO; the correct fix was to install SQL Server Native Client and a couple other things on the deployment server.)
Even after I removed the reference to BatchParser, I kept getting the "An attempt was made..." error, referencing the BatchParser DLL, on every ASP.NET MVC 3 page I opened, and that error was followed by dozens of page parsing errors.
If this happens to you, do a file search and see if the DLL is still in one of your project's \bin folders. Even if you do a rebuild, Visual Studio doesn't necessarily clear out everything in all your \bin folders. When I deleted the DLL from the bin and built again, the error went away.
if you get this Length cannot be less than zero. Parameter name: length issue in iis server configuation do the simple thing change the connection string in web.config file like your sql server name and server name and restart iis then try to load the page it works
Both are just regular projects, with no dependencies on any other non-.Net projects. Both are fully .Net - there is no native code, and no P/Invoke. I have other projects which depend on ProjectA and still work just fine.
I am pretty sure you're having a 32-bit / 64-bit conflict. It sounds like your main project might be set to 32-bit while the class its referencing is set to 64-bit. Try looking at this SO question and this one too. Between the two of them, you should be able to figure out your problem.
I had this same problem. I had set Project A's "Platform Target" ("Project A"(Right Click)->Properties->Build->"Platform Target") to x86 but kept Project B's at "Any CPU". Setting Project B's to "x86" fixed this.
I also had this problem. As mention before the problem was related to a 32-bit / 64-bit conflict, but with the site hosted in Azure. To change the plattform in Azure App Service, go to Configuration -> General settings.
The Chilkat .NET 4.5 assembly requires the VC++ 2012 or 2013 runtime to be installed on any computer where your application runs. Most computers will already have it installed. Your development computer will have it because Visual Studio has been installed. However, if deploying to a computer where the required VC++ runtime is not available, the above error will occur:
This also can happen just by having multiple supported frameworks defined in the app.config file and, forcing the app to run in a different .NET framework other than the one mentioned first in the app.config file.
It can be a little funny, but I had the same problem with normal working code. I added StreamWriter and StreamReader and it gave that error.The solution was I took that code into comment brackets then did debug and it started to work again
If you use LibreOffice from your program via cli .net integration like me, I got the same error. I use the older version of LibreOffice on the production environment on my PC I installed a newer version that was in conflict. Just uninstall LibreOffice. I found the solution here .NET CLI: Could not load file or assembly 'cli_cppuhelper'
More specifically, I somehow corrupted my opencv_core340.dll by accidentally adding SVN keywords to it, and thus my dll could no longer use it. However I don't believe that the solution to this problem depends on whether the dll is corrupted or missing. I'm just adding this for the sake of giving complete information.
I have detected something different from the other answers. Reaching this exception in my project was the result of a corrupt compilation. Without making any changes, just forcing rebuild, it was fixed.
I had the same issue. Project B in my case was a .Net Core Class Library which has a Nuget "Microsoft.Management.Infrastructure" installed. The error was that i called my project B "MI". I changed the project name to something else and suddenly everything worked again.
How long do you wait between commands? Some programs can be very long and after sending a load you need to wait for the program to be fully load, otherwise it will have an error.
Some programs might seem short, but if they have an URCap, the .script file underneath might be long. I got once a program with URCaps that generated threads on the program and had to wait like 2 seconds before sending the play.
I'm writing a plug-in for another program that is based on a public .NET API. Typically these plugins are made by creating a class library DLL that references the API assembly. Then a command class is created by inheriting from a base command class in the API assembly. The application is then set to reference the plug-in DLL file, and is then also responsible for actually firing up the custom command class when the user requests it.
However, now I'm trying to automate some code generation through System.CodeDOM, and want to create a simple console application that automatically generates new Class Types based off of types with in the API assembly.
System.BadImageFormatException was unhandled Message: Could not load file or assembly 'RevitAPI, Version=2011.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Usually I need to set the target framework of a plug-in assembly to 3.5. Yet now I've found that the error above goes away if I set the target framework of my console application to 2.0. However, my console application already references other class libraries of mine that have their target framework set to 3.5. And I'd really rather not rewrite them around the 2.0 framework.
These suggestions are accurate, but I wanted to add a note. I was stuck simply because I had multiple publishing configurations. I was editing the "Debug - Any CPU" and then deploying the "Debug - x64" configuration. Make sure you are editing and deploying the same configuration. Verify this by clicking the "Settings" tab after you begin publishing and the "Publish Web" dialog pops up. Make sure it matches the configuration you edited. (That's 4 hours of my life I will never get back!)
I had the same issue when getting my software running on another machine. On my developer pc (Windows 7), I had Visual Studio 2015 installed, the target pc was a clean installation of Windows 10 (.Net installed). I also tested it on another clean Windows 7 pc including .Net Framework. However, on both target pc's I needed to install the Visual C++ Redistributable for Visual Studio 2015 package for x86 or x64 (depends on what your application is build for). That was already installed on my developer pc.
My application was using a C library, which has been compiled to a C++ application using /clr and /TP options in visual studio. Also the application was providing functions to C# by using dllexport method signatures. Not sure if the C# integration leaded to give me that error or if a C++ application would have given me the same.
Please also note that the version of referenced dll file(s) which is in use is very crucial. I had almost the same problem with "Microsoft.WebView2.FixedVersionRuntime.101.0.1210.39.x64" when I tried to use the WebView2 component in the MMC Snap-Ins with types of "HTMLView" or "FormView".
I just copied the dll file (in my case WebView2Loader.dll, version 1.0.1248.0, size=157640 bytes) in a proper path that was accessible for the project (you could just put it beside your project output files first to test it) and then WebView2 browser started to function as expected. Microsoft error messages sometimes (at least in my case) was a little bit misleading and did not convey enough and to the point information.
I received "BadImageFormatException" that normally occurs when you mix platform targets (for example using a dll file compiled in X64 in an application that targeted for x86 or vice versa) or mix native code and .NET but that was not my problem at all. I hope this help one who may stuck in.
New UNO (not a clone) will not load program. I am using IDE 1.8.13, Windows 10 pro 64. I am successfully using the same system to load a Mega 2560. I have enabled verbose compile and upload. The compilation messages look good. I get the following upload message:
The two error lines are repeated 10 times. I looked at the troubleshooting page and the only item that seemed relevant was the possibility of no bootloader. I noted that the LED on pin 13 does not blink when I reset the UNO. Does that mean that there is no bootloader?
Hi ruilviana,
I have not loaded a driver. According to the documentation for the UNO, it uses the standard Windows driver - as does the Mega 2560. The correct comm port is shown and it is black. Opening the Serial Monitor works and it shows the proper values.
This would indicate the next step is to burn the bootloader. This requires an ISP programmer. If you don't own one, you can use a spare Arduino board as an "Arduino as ISP" by following this tutorial:
The step you missed is that you need to select "Arduino as ISP" from the Arduino IDE's Tools > Programmer menu. Please do that and then try burning the bootloader again.
Hi Pert, You are correct - I did miss that. I also tried both versions of Arduino as ISP. However, still no joy. Below is the verbose output of the upload. It looks like it cannot determine the device type.
I am using a 1 to 1 cable between the two ISP headers except that pin 5 on the Mega side is not connected and pin 5 on the UNO is connected to output 7 of the Mega. I edited the program accordingly. I do have the 10uf capacitor between RESET and GND on the Mega.