Attempting to build a Mixed Reality project I'm getting an (extremely long) error message, the meat of which is:
Error:
The command [...]\UWP\Unity\Tools\AssemblyConverter.exe" -platform=uap -lock=...
exited with code 1.
This is happening in Unity 2017.3.0f (but was happening with the previous version as well) and Visual Studio 17.
Unfortunately we have no leverage on this tool. The following unofficial workaround was published by a user: perhaps you should have a look to see if it can help you until you upgrade to a newer Unity (but it seems that they will only support IL2CPP builds going forward):
https://dotnetbyexample.blogspot.com/2018/05/fixing-unitytoolsassemblyconverterexe.html
Related
I tried searching but haven't found an answer. I upgraded SonarQube from 5.6 to 6.3 by taking the steps outlined here: https://docs.sonarqube.org/display/SONAR/Upgrading
SonarQube was upgraded and up and running quick enough, but then some problems occured. New results weren't being imported for alot of projects and even if they are, things aren't looking good.
The broken importing seems to be related to character set differences. I get crashes like: java.lang.IllegalStateException: Unable to read the source file : 'D:/Builds1/SF/CA AanvraagData/Sources/AAHG.AanvraagData.Client/AAHG.AanvraagData.Client.snk' with the charset : 'UTF-8'.
However, I only have the latest C# plugin installed as language plugin. Why is SonarQube even trying to read .snk files? I never had this problem before, and from what I understand SonarQube should only import known filetypes (sonar.import_unknown_files is set to it's default of false). I can manually exclude alot of extensions, but I'd rather not.
The few projects that actually get imported seem to have issues which presenting C# code in testclasses (no syntax coloring). Also the sonarqube runner gives alot of errors like this: Unable to TFS annotate the following file which is not in a mapped TFS workspace. A little further on in the output the annotating does seem to work for the same file all of a sudden. Also, I'm getting debug lines saying stuff like this: 'ontwikkel.config' indexed with language 'null'. Again.. why is it trying to index files other than .cs? Havent looked at these issues since they're minor in comparison which entire projects not importing, but if anyone has a suggestion that would be great.
Things I tried:
- Updating the scanner to the latest version (2.2), but that isnt helping. Reverted back to 2.0
- Manually excluding files - seems to be working to some extend, but I do not want to rely on this. I'm working with 60 other developers..
- Checking upgrade notes to see if I missed anything
- Checking jira for known issues, but I don't really know what to look for
Can anyone help me out here? Thanks!
With regards,
Whistler
There seems to be a bug in SonarQube 6.3 which results in the behavior I'm describing, resulting in projects failing to import when using in/exclusions: http://jira.sonarsource.com/browse/SONAR-8995
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 :)
When I try to install IronPython on Debian with Mono (3.12), I get the following error:
socket.cs(1900,63): error CS0117: `System.Net.Sockets.SocketOptionName' does not contain a definition for `IPv6Only'
How can I solve this problem? According to the IronPython website, everything should compile without errors.
In the Mono mailing list there is already such a bug, but there is no answer to this bug. Therefore I thought that maybe this forum is a better place for this question.
I'm no expert on either IronPython or Mono, but out of curiosity I just tried this.
For whatever reason, the IPV6Only value in the SocketOptionName enum appears to be missing in the Mono implementation. The error message you're getting is from the code in IronPython.Module/Socket.cs attempting to reference this. It turns out that this is already recognised in the codebase as a feature that not all platforms have, so there's an easy workaround:
The Common.proj project file in the Solutions/ directory in your git checkout defines a number of possible ReferencedPlatform values. The default value is V4. Just below there in the XML, find a block starting:
<PropertyGroup Condition="'$(ReferencedPlatform)' == 'V4'">
Nested in there is a Features element with a list of the features that apply, and if you find and delete FEATURE_IPV6 at the end of the list, then you should find that the project will build using make. I briefly tried firing up the ipy.exe that is generated and it seems to work.
Obviously this isn't a very good solution. Probably the best thing would be to file a bug report with the IronPython project. I guess that Mono on Linux is probably a fairly low priority for the guys who are working to maintain it.
Correct, up to mono 4.0 throws Protocol option not supported when setting IPv6Only false.
This is probably resolved here: https://github.com/mono/mono/blob/mono-4.2.0-branch/mono/metadata/socket-io.c#L536
But do note the compile flag IPV6_V6ONLY
I'm having a lot of trouble trying to track down the cause of this error message. I have a large Visual Studio 2010 solution which compiles without error on my local machine but on the build server, msbuild fails on one of the projects with the error:
fatal error CS0002: Unable to load message string from resources
Here's the red error section at the end:
Build FAILED.
"C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj" (default target) (9) ->
(CoreCompile target) ->
CSC : fatal error CS0002: Unable to load message string from resources. [C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj]
0 Warning(s)
1 Error(s)
The entire msbuild output from the build server is here: http://pastie.org/3660842
What does the error generally refer to, that would cause it to build locally but not on the build server?
UPDATE
I have just run msbuild /version on both machines and it turns out the .net framework versions are very slightly different. Local machine is 4.0.30319.488 and build server is 4.0.30319.1. I'm about to run windows update on the server to allow it to install some updates, as several seem to be .net framework-related, so I'll see if that makes a difference.
UPDATE
Installing the updates didn't help. Just remembered I copied up csc.exe from the async preview a little while ago in order to facilitate async compilation (the actual async preview had failed to install on the server due to visual studio not being there, but installing visual studio team viewer seems to have fixed that, so i've just run the proper async ctp3 installer to see if that makes a difference.
CS0002 is not documented. Interpreting the error message, I'd say that the compiler is trying to show you a compile error message but fails when it tries to retrieve the message text. Slightly odd is that it doesn't actually have a string table in its resources, not sure where it comes from.
Well, something is pretty borken. Your idea to update the .NET framework version is solid, that will update csc.exe as well. Ought to be good enough to fix any damage.
This is often a problem with the Entity Framework designer's handling of your connection strings. In your app.config file, make sure the assembly and resource names are what they're supposed to be.
Here's the format for that particular part of the connection string:
Metadata= res://<assemblyFullName>/<resourceName>
Ok based on my own experience of trying to solve the problem, as well as Hans's answer and a few other discussions I dug up while Googling, I'm guessing that the only way to make this error occur is to have an issue with current state of one's .Net framework installation. Essentially, a mismatch between the compiler and some other resource it uses means when the compiler hits an error, it tries to pull the error message from the referenced resource, but because the resource doesn't match the compiler build, the error message is unavailable and instead the compiler reports that it can't load the message (and thus can't effectively display the correct error message).
Hence the fix is to repair the .Net framework installation, which can be done by reinstalling it, running a repair on it, or installing a newer version (which in my case was the async ctp, which while not a full .net framework version upgrade, was enough to correct any mismatched resource references used by the compiler).
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