For some reason, even so much as typing this into a C# file in Visual Studio is enough to cause it to instantly crash. Why?
unsafe struct node {
node*[] child;
}
It seems to occur when the IDE would start coloring keywords and the like.
Trying it in TIO spits out csc.exe exited with code 1 which isn't very helpful.
While array declarations in C# are different than in C/C++, the above seems like it should be perfectly valid. Why isn't it, and why does it crash Visual Studio?
My Visual Studio version is 14.0.23107.
This is a known bug in Roslyn. This bug will affect any version of Visual Studio that uses Roslyn.
If I am interpreting VersionOf.net correctly, the first version of Visual Studio with Roslyn built-in is 2015. Before then, I think it was available only as an extension. So, Visual Studio 2013 and prior should be unaffected.
It's due to be fixed in the milestone 16 release. At this time, that release is not scheduled.
Because this is a bug in Roslyn, you can "get around" it by editing and compiling the code containing the unsafe struct in an older version of Visual Studio, one that predates Roslyn. Visual Studio 2012 should work. You can then use the resultant .DLL in your current software.
An unverified fix is available if you build Roslyn yourself from this branch. The fix was made in this commit.
Related
I recently updated from Visual Studio 2017 Community Edition to Visual Studio 2019 Community Edition.
Now, if I build my solution with errors, they will show up in the build output, but not all of them will appear in the error list. It would appear only errors of open files will show up in the error list. This is incredibly annoying.
I am not alone in this issue. It has been reported many times on Microsoft's forums, but no one has a definitive solution.
I have tried a variety of solutions people suggested in those threads:
I have ensured the filters are legitimate: Entire Solution, Errors enabled, Build + Intellisense.
I have tried deleting the .vs folder and restarting Visual Studio.
I just updated to the very latest Visual Studio 2019 version. Supposedly there are many different versions of this error, happening in versions of Visual Studio all the way back to 2017. Some supposedly have been fixed...?
I have disabled parallel project loading.
I have experienced this before in other versions of Visual Studio with Razor pages. To my knowledge, that's to be expected in Razor though.
The only other factor that I severely doubt impacts anything is that it's a Visual Studio project generated by Unity editor. From what I've read, ASP.NET, Razor, Xamarin, and other frameworks have each had their own version of issue reported. Perhaps Unity is afflicted by it too, but I don't see how or why. I doubt Unity's auto-generated Visual Studio projects are that different from your standard library projects.
I have now installed Visual Studio 2019 on two separate machines, and it appears that "Full Solution Analysis" is disabled by default.
Simply check the checkbox in options and everything seems to work as it did previously:
For those using Visual Studio 2019 v16.9.1 make sure your Error List window looks something like this:
The important part for me was selecting Build + IntelliSense (previously it was set to Build Only which explains why the error list would only refresh on build).
In my case the solution was to switch off 'Tools->Options->Projects and Solutions->General->Show output window when build starts'. Even though the 'Output' window showed "0 succeeded, 1 failed" it would not switch back to the 'Error List' window even that the checkbox above 'Always show Error List if build finished with errors' should have moved it to 'Error List'. Clearly a bug in Visual Studio 2019 which was not present in Visual Studio 2017 (I just finished updating).
In my case, it was the fact that I was building under a Release profile. Once I chose Debug from the dropdown next to the Start Debugging button, it started showing my errors in the Error List after a few seconds.
In my case it was since the dependency dll was built for x86, but in the misbehaving project its reference was with processorArchitecture=MSIL
I have error in my project on time of build csc.exe exited with code -2146232797 visual studio 2017(Professional) in other Team's computer project building and running fine, so I not want to update nuget compiler,
Is there any permanent solutions there?
This issue happened for some people with vs 2017. you need to reinstall .net via
microsoft site
as requested and if the above link does not help, there is a thread in visual studio development community stating they fixed the issue in visual studio 2017 v15.5:
We have fixed this issue and it's available in Visual Studio 2017
version 15.5. Thank you for helping us build a better Visual Studio!
more over, there is another solution stating:
using the 2.2 compiler made the problem go away.
Multiple times I got this issue in VS 2019. I closed other VS projects and then build successfully.
I have a relatively large WinForms application that has been developed under Visual Studio 2013. I recently upgraded to Visual Studio 2015 on another computer and have been trying to get the project working under it.
My first issue/concern is that when I open the project for the first time in Visual Studio 2015 it does not ask me to "upgrade" the solution to Visual Studio 2015, it happily just opens the solution. I am used to having Visual Studio ask to "upgrade" the solution and create a new .sln file that is recognized as a, for example, Visual Studio 2013 solution instead of the old VS10 solution.
The actual issue I am facing is ~10 errors that seem to deal with cryptography. From what I can guess this has to do with the solution itself and what microsoft does with it in the background seeing as the most cryptography I use in the project is generating Guid.
An image of the errors
The one other issue I have is that, as I am not used to, I cannot double click on the errors them self to be lead to where Visual Studio thinks they are occurring. Thus I am not sure what is generating them or where to go from here.
Any suggestions?
This is a Windows 7 installation on an older model Lenovo Thinkpad. I do not have admin privileges on this computer either.
EDIT: So far I have tried to add <enforceFIPSPolicy enabled="false"/> to the file Visual Studio 15 settings at C\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Devenv.exe.config, though whenever I try to edit it (even after a fresh restart) the file is "always" opened by another program. So it seems I cannot edit the file to turn off FIPS for Visual Studio 15.
I am still open to suggestions or clues.
EDIT2: I have managed to get <enforceFIPSPolicy enabled="false"/> into the IDE settings with the help of IT (Using this article). Though this seems to do absolutely nothing, it seems that it is being ignored.
Another issue/clue here is that even if I create a brand new C# project in Visual Studio, when I try to compile I receive the same errors. So I have to assume that Visual Studio is using the SHA256 class somewhere "in the background". If I did have control over its usage I would try to implement #Kevin 's answer below.
I have found another possible solution on the web though I am not sure of its validity
VS 2012 now builds C# projects in a separate process that runs
msbuild. The entry you added to devenv.exe.config (that worked for VS
2010) won't be seen by this process. You should add the same entry,
namely
to the config file for msbuild; typically that's found at
c:\Windows\Microsoft.Net\Framework\v4.0.30319\msbuild.exe.config"
I will try to get this done when I have time for the .NET 4.5+ msbuild.exe.config files and report back.
The solution I went with is outline here.
<enforceFIPSPolicy enabled="false"/> was added to a few files, namely
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe.config
C:\Windows\Microsoft.Net\Framework\v4.0.30319\msbuild.exe.config
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Devenv.exe.config
Though I think the one that actually made it work was the first file.
You can't double click on the error and have it go to where the error is being thrown because it is being thrown inside the SHA256 class. If the FIPS compliance bit is set, any non-FIPS compliant .NET cryptography classes throw this error.
You have two choices to fix this...
First, you can just turn off the FIPS compliance bit on the machine where you are trying to run the app (not recommended).
Otherwise, you can update the code to use the FIPS compliant version of SHA256 (SHA256CryptoServiceProvider). This will require .NET Framework 3.5 or greater.
I have experimented with implemented Roslyn Code Issues and Fixes in Visual Studio 2013 when they discussed it in BUILD 2014.
We want to be able to right custom rules that will cause either compiler errors or warning and additionally if possible give visual feedback in Visual Studio.
If possible, it would be nice to provide this in VS2012 and later, but the last time I checked, the ability to do this through Roslyn was in 2013 and later.
I do not have any specific attachment to Roslyn, but I am not aware of the ability to do this elsewhere.
Is there any other way to provide custom code issues and fixes int he IDE, or is it only through Roslyn in 2013?
You can only do this using Roslyn on Visual Studio 2015.
The Roslyn End User Preview for 2013 is a much older version of the APIs and is not supported.
I have recently found out that (merely) installing Visual Studio 2012 on my machine, causes Visual Studio 2010 to use the newer C# compiler. This happens even when setting the language version to 4 (http://ericlippert.com/2013/04/04/what-does-the-langversion-switch-do/).
I wanted to know if it were possible to force Visual Studio to use the old compiler anyway. I think it's not possible because it seems that the compiler is installed in the framework folder which is the same for .NET 4 and .NET 4.5, but I was wondering if someone managed to do it anyway somehow.
You can use the command line compiler see here, and run your code on the old compiler in post build actions
As I said in my original question and as some commented, it indeed seems this would be impossible. The new compiler is installed in the same place as the old compiler. One would need to have a clean build environment with the exact compiler needed.