Every modern version of JSIL I ever try to get working with XNA ends up with this error.
Everywhere I've ever looked in the past for information about why it doesn't run ends up with an answer about XNA 4.0 not being installed properly or something.
This error was reproduced on 3 different computers.
I CAN get A version of JSIL working, I can download one of the releases from the git repository (JSIL-0.7.6) and it'll work with XNA providing you don't give it anything the build is unable to support.
But those releases are a couple of years old now. It would've been nice to get a modern build working.
I try to offer up some speculation but I'm sort of out of my depth here.
JSIL-0.7.6 - won't build in AnyCPU, requires the solution platform be set to x86.
Latest JSIL git release - A lot of the projects are now set to AnyCPU and setting them to x86 will create a various mixture of errors or warnings.
So I think somewhere along the line I might be having problems with a build at the point certain projects in JSIL went from x86 to 64 bit support.
I have visual studio express 2010 and visual studio community installed.
I've tried things like using XNA refresh. Using emscription, FNA, etc...
In an ideal world I'd rather get JSIL working with monogame but I get so many errors on any version of JSIL it doesn't seem to be worth bothering. Porting monogame projects to xna isn't too much trouble.
Trunk JSIL is designed to be built using VS2015 Community. Most of the dependencies have moved over to NuGet, which means that you need to restore packages before building for the first time - VS2015 will do this for you automatically; at the command line you may need to do a manual NuGet package restore.
If you want to use the XNA support, you'll want to compile as Debug|Any CPU or Release|Any CPU. This should still work because the compiler - JSILc - has 32-bit and 64-bit targets now. If you use the 32-bit target (Compiler.Executor.32bit) that will ensure the compiler is running in 32-bit mode and the XNA bits will work. The 32-bit target builds as JSILc.exe and the 64-bit target builds as JSILc.AnyCPU.exe.
As far as the content pipeline bits go, I'd need to see more log text to speculate as to why it's not working... but in general, the content pipeline does not work reliably in command-line msbuild. Your best bet is to first build the game project a single time using Visual Studio so all the content is built correctly, at which point command-line msbuild will handle it better.
For XNA in VS2015, use the VS2013 package from codeplex:
https://mxa.codeplex.com/releases
You may need to edit the manifest inside the package before VS2015 will let you install it, but it works perfectly.
Building with VS2013 will probably work fine, but I haven't done that recently.
If you're still having trouble, try ruling out the basics by doing a NoXNA build (Debug|NoXNA instead of Debug|AnyCPU) and make sure everything works there. An easy way to verify a working build is to run the 'SimpleTests' test suite using the VS2015 test runner - it takes a relatively short amount of time and will identify basic issues with the compiler or build pipeline.
Keep in mind that when you invoke tools like msbuild or csc from the command-line, it's somewhat unpredictable which version you'll get. VS2015 x64 native tools command prompt and VS2015 x86 native tools command prompt are two start menu shortcuts that will get you a command prompt with the right tools loaded if you have VS2015. Given that you have VS2010 installed, it's possible that old versions of msbuild and/or csc are being used when you try to build.
Related
Before any question, I did a lot of research on Google and S.O. , and I found only old and obsolete threads without any help for my problem.
so...
1. First question:
I wonder if it's possible to target the installed Mono framework directly from Visual Studio 2019.
I know that at the time of writing, Mono 6.4.0.198 is released and it supports almost all features of .NET 4.7 (and C# 7.0), so I created a simple project targeting FW4.7.2 and it works fine so far.
I just wanted to know if I can create a project entirely on Mono Framework with no other reference than Mono assemblies.
I did a lot of research and the only thing I found is this: https://erictummers.com/2012/01/25/target-mono-from-visual-studio/
but i'd rather not mess with the registry and assemblies files.
2. Second question:
I would like to build and debug my Mono code directly on the target machine (Raspberry Pi). It's possible to do so in Visual Studio 2019?
I managed to compile a C++ program directly on the RasPi, so i thought it might be possible to do the same for Mono/C#.
Any help would be very appreciated!
The Context
We'd like to modify Roslyn and be able to debug it while compiling with it. Pre-VS2015 release, doing this was a painful process that didn't flow very well.
Our goal is to develop a C# variant compiler.
The Dream
Pre-VS2015, executing and debugging your modded Roslyn required the opening of a second VS IDE (experimental) set to use your modded Roslyn. This process wasn't straight forward to setup properly, and oftentimes would break your VS2015 installation.
Post-VS2015, is there a better setup and process possible to modify and debug Roslyn?
I have installed Visual Studio 2015 but it looks like I need more required bits. After that I'm unsure how to run the tests and try the changes in VS2015.
We have our current documented process of testing your own versions of Roslyn here. As long as you're on Visual Studio 2015 Update 1 or later (where we did all the work to support this), everything should work.
The executive summary of those instructions is if you now enlist into Roslyn, you can choose the "VisualStudioSetup" project and just hit F5 to run. That builds to .vsix files in your build directory you can also install. If you want to, there's a CompilerExtension project that produces a compiler you can build with.
I'm trying to use the Resharper CLI tools within our CI set-up to perform static code analysis.
I've tried this on two different VMs and got very different results, on one machine everything seems to work fine on another it seems very unstable.
Sometimes I got errors like access violations, sometimes it seems to be realted to the logger crashing, but even if I get no errors it doesn't seem to find all the projects in the solution during the analysis.
Both machines set-up is:
JetBrains Inspect Code 10.0.2
Running in 64-bit mode, .NET runtime 4.0.30319.34209 under Microsoft Windows NT 6.2.9200.0
The main difference between the machines is one has Visual Studio installed and one doesn't.
On the machine that is unstable I do see errors related to imported projects not being found (such as Microsoft.Portable.CSharp.targets) which i think are related to Visual Studio not being installed?
I also see:
PlatformInfo must be found for platformId=.NetFramework,Version=v4.5
Could anyone tell me what the minimum requirements are on a machine for running the Resharper CLI and is Visual Studio part of the requirements? And in particular what would cause the tool to not be able to find all the projects in a solution?
It turned out the failure to find all the files was because certain projects in the solution were being ignored because of missing or invalid references.
The fix was to install the following to the build box.
Xamarin for Visual Studio (we are building Xamarin applications)
Portable class library support as detailed here: http://lastexitcode.com/blog/2014/11/16/InstallingPortableClassLibrariesForXamarinStudio/
.NET 4.5.1 Developer Pack: https://www.microsoft.com/en-gb/download/details.aspx?id=40772
With all this installed the analysis appears to be working fine.
I get an AccessViolationException when I run the Google Drive API sample in Visual Studio 2012 on Windows 7 x64. My project is targeting .Net 4.5. I get the exception on line 185:
await service.Files.Delete(file.Id).ExecuteAsync();
It happens in both Debug and Release modes, and in all platforms (x86, x64, AnyCPU).
It does NOT happen when I run without the debugger attached ("Start without Debugging").
It does NOT happen when I enable the "Enable native code debugging" in the Project properties.
Any ideas why enabling native code debugging might prevent the exception?
Note: running the sample requires the NuGet package (prerelease): Google.Apis.Drive.v2
EDIT: I wish Google people would chime in and tell if they've seen this as well because the sample instructions say:
Open the GoogleApisSamples.sln with Visual Studio
Click on Build > Rebuild Solution
Execute the .exe in Drive.Sample\bin\Debug
which is weird since they go out of their way to execute the exe directly from the debug folder instead of just saying "Run the sample".
It is just a shot in the dark, but I had a similar issue which turned out to be caused by the visual studio hosting process.
you can disable it and see if anything has changed.
You can do it from Project properties > Debug > uncheck the Enable the visual studio hosting service
I also had this problem although with a completely different project. for me the initial problem was that the wrapper library was a .net 2 assembly and my application was a .net 4 app. When i changed the wrapper to .net 4 i started getting stackunbalancedExceptions instead.
This turned out to because the callingconvention (and perhaps the charset) property for the DllImports was not set correctly. Once i fixed this i no longer get any exceptions in .net 4, however i still get them when compiling the wrapper library as .net 2.
There might be a compat settings that can make it work with mixed 2/4 framework, but since i was able to recompile i haven't really checked.
We use Make to compile our product, which includes, C, C++, Java and a bunch of other bits and pieces. As much as possible we have all tools required to compile the whole thing checked into source control, to eliminate local dependencies and to ensure consistency across dev machines.
Recently we've added some components written in C# using Visual Studio and would like to take a similar approach with Visual Studio solutions. Shelling out to devenv isn't a good option. Calling csc.exe directly (as I've done before using Nant) would require keeping track of file dependencies in the build script, which I'd rather just let the Visual Studio solution do.
MSBuild seems like a good bet, though its default location in %windir%\Microsoft.NET\Framework\[version]\ makes me worried about variability between machines, both with the [version] in the path and the fact that you'll see both "Framework" and "Framework64" directories. I wouldn't mind having a requirement that all developers have whatever .NET framework version installed, but I do worry that your v3.5 might not be the same as mine.
Does anyone have a solution to this that they like? Tried anything that you really didn't like?
MSBuild is the lowest-friction option for sure. Different fx versions aren't that big a deal at build-time- if you're using something important from a fx version higher than what's installed, it won't build. The last place I was at, we built a huge multi-environment build system with NAnt as the base, and it hooked out to MSBuild with NAnt's MSBuild tasks. MSBuild is fine on its own if you're just doing MS stuff, but we had a bunch of things that MSBuild didn't natively support, hence the NAnt wrapper.
I agree with everyone else. To make it easy, just make vsvars.bat (the batch file that is the Visual Studio Command prompt) part of your build script, and then MSBuild will just work.
We use Nant to drive msbuild. If you're worried about different versions of the framework, particularly service packs, use FxCop to check that you're not letting unexpected dependencies creep in. Details are in this answer.
MSBuild is the right tool for this job. Just match your framework version to the version of the framework bundled with the Visual Studio you're using.
32-bit versus 64-bit shouldn't matter, I don't think -- I'm pretty sure both the 32-bit and 64-bit editions of Csc.exe can cross-compile to the other platform. The MSBuild project file (*.*proj XML file) should contain everything MSBuild needs to build your application.