We Keep Coding

Mono framework on Visual Studio 2019 - target/compile/debug

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!

CefSharp - Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies

I've been working on a CefSharp WinForms app for a few weeks and I've had no issues with it. This morning, while adding a few things to the application, I tried to run it to test something and got the below error:
System.IO.FileNotFoundException was unhandled Message: An unhandled
exception of type 'System.IO.FileNotFoundException' occurred in
mscorlib.dll Additional information: Could not load file or assembly
'CefSharp.Core.dll' or one of its dependencies. The specified module
could not be found.
After searching for a while I found this:
https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions#Runtime_dependencies
I checked bin/Debug/x86 for the project and all of the dependencies appear to be present. More importantly, it had been working fine five minutes earlier, and I didn't touch anything beyond a single class for an Entity Framework migration.
I've tried cleaning and rebuilding the solution, restarting Visual Studio, restarting my PC, and clearing out /bin/Debug, and none of these have helped.
Why would this error appear now after several days without it, and how can I resolve the issue?
Edit: I've done some further experimenting and I'm able to get the application to run in Release mode but not Debug mode. If I change the output path of Release mode to Debug, it fails with the same error (likewise, it succeeds in Debug with the Release output path).

First, make sure you installed the Microsoft Visual C++ Redistributable:
Version v93 and above: use Microsoft Visual C++ 2019 Redistributable or greater
Version v65 - v92: use Microsoft Visual C++ 2015 Redistributable or greater
Older Versions: use Microsoft Visual C++ 2013 Redistributable (exact version)
You could download the Visual C++ Redistributable from Microsoft. See C++ binary compatibility between Visual Studio versions for more detail on the version compatability.
Make sure to match the correct architecture, if your application is x64, you need to install the x64 build of Visual C++ Redistributable. Likewise if your application is x86 then you need to install the x86 build of Visual C++ Redistributable.
The Microsoft Visual C++ Redistributable depends on the Universal CRT. The Universal CRT is included as part of Windows 10/11. On older versions of Windows the Visual C++ Redistributable will install the Universal CRT.
For those wishing to include the Visual C++ Runtime with their application it's technically possible to include the runtime with your application. See also Local Deployment section of the Deployment in Visual C++ article from Microsoft.

I had the same problem until I installed the following redistributable:

SuperBerry's solution of installing VC++ redistribution package solved the problem for me. I'll just provide a little troubleshooting insights from my naïve perspective.
The error message is pretty clear, either the assemble CefSharp.Core.dll is missing or one of it's dependencies. So the question boils down to how do you figure out what is missing?
So first, do you have CefSharp.Core.dll? In the Solution Explorer look at the references for the project that is having this problem. You should find a reference to CefSharp.Core. If you can't find one, you're missing that assembly. If you have one, then the problem is that you're missing one of its required dependencies. When you click on the CefSharp.Core reference, in the detail, you'll get the full path to where it's located. In my case, it was in located at 'C:\Users\tom\source\repos\MyProject\src\packages\CefSharp.Common.41.0.0\CefSharp\x86\CefSharp.Core.dll'.
You then need to get a list of the CefSharp.Core dependencies to figure out which dependency your missing. Dumpbin.exe is a command line tool that you can use to get a list of dependencies. In order to use dumpbin, you need to make sure that it can be found on the path in your system environment variables. I found on the path of the VC Tools bin directory. In my case, I found one at: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\Hostx64\x64'. Open a Command Prompt terminal and navigate to the folder containing CefSharp.Core.dll and key in the following:
>dumpbin /dependents CefSharp.Core.dll
the result I got was:
Dump of file CefSharp.Core.dll
File Type: DLL
Image has the following dependencies:
KERNEL32.dll
MSVCP110.dll
MSVCR110.dll
libcef.dll
USER32.dll
mscoree.dll
Not having worked with Microsoft Visual Studio for a number of years, I had to try and figure out where those dependencies are suppose to be located so that they can be resolved. I simply did an internet search such as "where is Kernel32.dll located" doing that for each dll until I found the missing dll. In my case, I could not find MSVCR110.dll, so I strongly suspected that was my problem. I then did an internet search for "MSVCR110.dll is missing" and found out that it was part of the vc++ redistribution. (SuperBerry, you were right on your first point). I also found that it could be downloaded from: 'https://www.microsoft.com/en-us/download/details.aspx?id=30679'. I downloaded both the x86 and x64 versions (although I only needed the x86 version for this project). They are executables that when run installs them. After installing them I found a copy of it in 'C:\Windows\SysWOW64' and in 'C:/Windows\System32'. And low and behold this problem was resolved.
What I learned from this process, was that it was difficult to know whether you have the right VC++ redistribution package installed or not. I thought I would have been installed when visual studio was installed with the VC++ features enabled. I'm using visual studio community version 2019. The project I am working with was a project I cloned from a GitHub source. I'm still confused about VC++ redistribution versioning. For example, could I have installed some later version and would it have worked (i.e. backward compatibility)?

I had the same issue. what worked for me is to add
<CefSharpBuildAction>Content</CefSharpBuildAction>
to the first PropertyGroup inside the csproj of the project you are dealing with.

I had the same issue even in release mode. Going through GitHub CefSharp FAQs, NOTE 2 solved my issue.
If compiling from source (not recommended, use the Nuget packages) and you notice that you can no longer build in debug mode, but release builds work just fine you may need to repair your version of Visual Studio. This happens in rare cases where you will get the same exact message as a missing unmanaged .dll file as shown above.
Had to repair Visual Studio and all started working as before.

For my future me, had this same issue and every time i get this error when i start my .net core 3.1 wpf application in visual studio -> Could not load file or assembly 'CefSharp.Core.Runtime.
That cost me hours!
My Solution: Don't initialize Cef in your WinForm or WPF Window class.
You need to initialize this in your startup main/app. In my example i need to add this:
public App()
{
CefSettings _browserSettings = new CefSettings();
...
Cef.Initialize(_browserSettings);
}

Visual Studio Code on Linux - How to run a C# application when "app.js does not exist", nor should it

I am running VS Code on Ubuntu 14.04. I am trying to run a C# web application which my team can run just fine in Visual Studio on Windows. The problem is that Code gives me an error message, "/app.js does not exist". No such file exists in our project, and I think I want to run it using "Startup.cs" instead, but despite trying to change the 'launch.json' file accordingly, another file that my team does not have, I still cannot get my project to run. Has anyone experienced a similar problem?

The .NET environment for Linux is currently in a pretty early state. Thus you can't do everything on Linux that you can enjoy on Windows.
If you want to develop an ASP.NET application then you should read this guide on how to setup the environment to work with Visual Studio Code.
If you have a C# application that can already be compiled and run on Linux then you can
create a script file which compiles the project and runs it afterwards
and let this script be executed as the build task in Visual Studio Code. Here is how to do it: How to prepare/configure development environment for C++ projects in Visual Code Editor?
Just for your interest: You can't currently debug C# projects in Visual Studio Code.

Perhaps you can try to open the project with Monodevelop? This is an open source IDE for C# that runs on linux. It is compatible with VS projects.
You will probably need to also install Mono (the open source .net runtime) to run Monodevelop.
You may even be able to run your web app with the Mono runtime, although it has been always a bit behind the official Microsoft .net runtime (you may get 'class not found' exceptions if your code uses libraries that are not yet implemented in the Mono runtime).

Trouble getting JSIL to compile

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.

AccessViolationException goes away when native code debugging is enabled

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.