When compiling my C#-project referencing a project cloned from CommandLine I get this error:
Error 2 The command "ClassLibGenerator.paket/paket.bootstrapper.exe"
exited with code 3
However when I use the VS-solution provided within the clone and compile the CommandLine-project there everything works fine.
Both solutions - mine and the one from the clone - contain the same project - CommandLine.
I can´t finf what the error-code means nor do I know why bootrtrapper is needed or what it actually does in this context.
Not sure if this is of any use, but had a similar problem with "paket.bootstrapper.exe exited with code 216", there were also a load of missing references (see later). This was the only SO question I saw so hopefully this may be of use to someone.
Paket is a package manager which is a kind of suped-up NuGet. bootstrapper.exe is a program which downloads the latest manager.
http://fsprojects.github.io/Paket/bootstrapper.html
What I did to fix my problem was to go to Tools->Extensions and Updates->Online and install Paket. Restarted Visual Studio, and tried to recompile. This time it resolved my missing references, but still had the 216 error. Turns out this is 32-64 bit compatability error. I downloaded the newest version of "paket.bootstrapper.exe" from
https://github.com/fsprojects/Paket/releases, overwriting the existing bootstrapper.
This got me compiling again :)
Related
The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Build.Tasks.Core.dll". A required privilege is not held by the client SkyOnTheWay.Toolkit.Test
=> This occurred all of sudden. I was compiling OK. After changing some code and tried to build again, all of sudden it fails with above error. Cannot go further.
I updated all nudget packages, updated visual studio 2019's updates available, restarted computer several times.
Nothing works. Those answers out there internet are similar but all are little different and nothing worked.
I use VS 2019 and was building Universal Windows' app.
I further test with new project to confirm it's not code issue.
I added new project - Unit Test App (Universal Windows)
Then, compiled. It's OK.
I installed Win2D.uwp nudget. (1.24.0)
Then, compiled. It causes the Error. Nothing further can be done due to the error.
** I have used Win2D for years and no problem. Now all of sudden this causes and big issue.
Also, the error does not occur on class library.
I heard other people complaining the same issue; No change at all, all of sudden 'CodeTaskFactory' error occurs!
Anyone found a workaround or fix?
I installed LibGit2Sharp via NuGet into a VS add-on I'm (re-)writing (Visual Studio 2015). The code compiles fine, but it barfs when I try to allocate the Repository:
using (var repo = new Repository(#"C:\Path\MyProject"))
The thing is, it used to work. I was testing it out, and the code ran fine. Then--bam--I ran it again and it stopped working. The specific error:
{"Unable to load DLL 'git2-785d8c4': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}
From what I understand about NuGet--which isn't a lot--it's supposed to set all that up so I don't have to worry about it. So I uninstalled it and re-installed it.
The weird thing about LibGit2Sharp is the old version shows up first (v0.22.0) and "version 1" shows up second (v1.0.160). I installed 0.22.0 the first time, so I tried the second one (v1.0.160) the next time. But v1.0.160 didn't work at all (none of the code compiled, errors galore). So I uninstalled v1.0.160 and installed v0.22.0 again. Now it all compiles again, but I get the error above.
Does anyone know what's going on?
For others who might come into this thread in the future:
Put 'git2-785d8c4.dll' in the same directory where your output exe is, then it will work.
you can find it in ..\LibGit2Sharp\bin\Debug(Release)\lib\win32\x86
Is it possible that the .NET framework version your project targets has changed? Are you able to target .NET framework version 4.5 (rather than 4.51 or any other higher version, such as 4.6) and try again?
I've got a C# program that was built as a Windows service. I tested this last week and it worked fine, but today I'm getting an error.
When I try to install using installutil.exe, I get the error:
Could not load file or assembly [file name] or one of its dependencies. The module was expected to contain an assembly manifest.
Rebuilding the project had no effect. I also noticed in task manager that the service is still listed and running. On the chance that might be interfering with the installation, I tried uninstalling via installutil, but got the same error message back again.
I've seen many other questions related to this error, but most of them have either no answer, or a very specific answer related to their unique situation. Has anybody had this happen, and how did you fix it? Any ideas are appreciated.
Update:
I successfully uninstalled the service using the "sc delete" command via command prompt, but I'm still getting the same error from installutil on trying to reinstall.
Update 2:
Just for the sake of trying something, I deleted the bin folder from the project, reopened the solution, and did a clean and build. It still won't install, but now I've got a different message:
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Question:
What would cause there to be a mismatch in runtimes? As far as I know, I've only used .NET Framework 4.5 and haven't deviated. Is there a value I should be looking at / changing to fix that?
Update 3:
Here's what I've tried so far:
One answer suggested the version of installutil being used matters. I'd been running v2.0.50727, but there's also a v4.0.30319 I hadn't thought to try. Running this resulted in:
An attempt was made to load a program with an incorrect format...
I'd be willing to work on that error instead, if it would solve the problem. However, I'm compelled to think that's not the problem since I'd been successfully running v2.0.etc just before the first error popped up.
Inside App.config, there's a line "supported Runtime version=v4.0". I switched this to 4.5, but it had no effect good or bad.
I tried switching the target framework (under project properties) down to 4.0, but this cause an error with:
Some NuGet packages were installed using a target framework different from the current target framework, etc...
This was referring to the EntityFramework, and I'd rather not start messing with NuGet again unless it's the only way (last time it was a nightmare).
I tried installing the service on the target server (the machine it will eventually be deployed to) and got the same error. This leads me to think it's a problem with the project / solution and not the pc.
Looks like a assembly loading problem. Use the Fuslogvw.exe utility. Start it from the Visual Studio Command Prompt. Click the Settings button and click the "Log binding failures to disk" radio button. Switch back to VS and start the program and wait for the exception to occur. Back to Fuslogvw, click the Refresh button and double-click the added entry. It will show you the file it found.
One another possibility is to trying to load a .NET 4 assembly with an EXE that asked for CLR version 2. That requires an app.exe.config file that forces CLR 4 to be used.
I am trying to get SWIG to work with Visual Studio and C#.
I downloaded swigwin-2.0.4.zip and converted the project to a VS 2010 project.
I am able to build the 'class' example. When I then try to run compiled build I get the error
The type initializer for 'examplePINVOKE' threw an exception.
I haved googled the error, but have not found any suggestions on how to resolve it.
Hope somebody is able to help!
Thanks,
Christian
What worked for me was to:
Go to Build->Configuration Manager. For the C# project change AnyCpu to x86 and rebuild.
Copy example.dll to bin\x86\Debug (Release).
Doesn't require CorFlags.
I got the following answer from Gregory Bronner on the swig-user mailinglist:
I had this issue as well (VS2010 , Windows 7, 64 bit computer, 32 bit mode dll, .NET 4) :
The problem actually relates to being unable to load the DLLs
There were two causes:
#1: All DLLs used by the C# assembly need to be in the same directory (or you need to change the lookup paths).
#2: The C# or the C++ DLL (I forget which) had incorrect CofFlags -- use CorFlags /32Bit+ *.dll or something like that. You could also try using /UpgradeCLRHeader
#3: You need to target the .NET 4.0 system in the project file, but 1 and 2 should get you started.
I will try these hints out and see whether they work and then post an answer if I am able to resolve the issue.
The solution for me was
Move the used dll's to the Release (or Debug) directory
Run CorFlags /32Bit+ file.exe
where file.exe is the executable produced by building the code.
For more information on what is going on Í found the following links helpful
http://www.davesquared.net/2008/12/systembadimageformatexception-on-64-bit.html
http://blogs.msdn.com/b/joshwil/archive/2005/05/06/415191.aspx
For about 2 weeks now, I have been unable to run any UnitTests (built in VS unit tests) for a project. Previously everything worked fine. The error message is:
Could not load file or assembly 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProjectName.XmlSerializers.dll" or one of its dependencies.
The project references System.Xml.Serialization and uses the XmlSerializer class; just like many other classes/projects I've written. For some reason, only this project is affected. It builds fine, runs fine, I just can't run my unit tests.
I've checked the directory, and all the dlls in that directory are Microsoft dlls. The dll that it is looking for obviously is not a Microsoft dll.
Anyone have any ideas?
Edit:
It apparently has something to do with using the XmlSerializer and it generating that file automatically instead of using sgen.exe. Here is a link to the MSDN article. From what I've been able to find, it has something to do with using the serializer with generics. None of the sources I've found seem to offer any way to make it actually work.
First enable loader logging (using FUSLOGVW.exe from the SDK) to confirm what is not being found.
Then use Reflector on all your assemblies to find the one that is trying to load the non-existent assembly. If you find no such assembly it must be being loaded dynamically, in which case attaching to AppDomain.AssemblyResolve should allow you to identify where.
try to copy all your source files somewhere, then delete the project and try to make it from scratch. Maybe something happened with project dependencies
Is your computer 64bit? I got the same error when trying to run a 64bit dll with NUnit that was set to work as an x86 assembly (using corflags).
You can probably find out from the error message (use FUSLOGVW.exe lick Richard suggested).
If that is the case you can either sent the dll or NUnit to run as the correct assembly using corflags.
Solution
As it turns out, the problem was with VMWare. I installed the latest version of VMWare, and it installed it's tools to debug in a VM. Something it installed or changed caused this problem. When I uninstalled VMWare, the problem went away. So, I reinstalled VMWare without installing it's debugging capabilities and the problem did not come back.
Workaround:
I still have no idea why this problem suddenly started occurring, but I found a hack to make it work.
I had to go to project properties => Build Events and add this line to the Post-build event command line:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" "$(TargetPath)" /force
This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"
Now it I can run my tests and step through them. The problems I have now are 1) I have to remember to copy the dll to that directory every time I change something in the classes that I am serializing, and 2) I now get a ThreadInterruptedException when a test finishes running; thus 3) I can only run one test at a time.
Not a good solution, but at least I can limp through. Unfortunately, redoing everything, as Nikita Borodulin suggested, is not an option.