I have a solution for VS2010 that includes some F# projects that work against the F# 2.0 compiler/SDK, leveraging fparsec and fsharp powerpack.
I then upgraded my main development machine to VS2012, loaded the solution and was able to compile just fine.
However I just repaved a seperate machine with windows 8 and VS2012, and loading the solution on that machine causes compilation failure, as the project is targeting F# 3.0, and fparsec/fsharp powerpack don't appear to compile any more.
Is it possible to install the FSharp 2.0 SDK (and if so, where do I get it from?) on this new windows 8 machine and get the solution to compile again, or would I need to do something else to get this working on both the old and new machine?
Updated 2012-10-25
Compilation is now working after restarting VS2012, but when executing code I'm getting an unexpected error related to my F# code:
Method not found: 'ParserResult`2<!!0,Microsoft.FSharp.Core.Unit> FParsec.CharParsers.run(
Microsoft.FSharp.Core.FSharpFunc`2<FParsec.CharStream`1<Microsoft.FSharp.Core.Unit>,
FParsec.Reply`1<!!0>>, System.String)'.
This does not happen when compiling/executing the same code on a machine that had first VS2010 installed with F# and then was upgraded to vs2012 - only happening on the machine which has just vs2012 installed.
Any ideas?
If you set the target framework to "4.0" (or lesser), it should compile the same as F# 2.0 (with a few new nice features, such as auto properties). I see no reason to insist on leaving out the new features, and definitely no reason to leave out all the bug fixes that came with F# 3.0 .
Related
I use VS Code as my IDE. Today I saw in my C# files that I could no longer use things like "Go To Definition/Implementations" or hover over anything to get the path/type etc.
I found my Omnisharp console and saw they updated last night and there is an error:
Error: Found dotnet version 5.0.201. Minimum required version is 6.0.100.
I can't upgrade my dotnet because 6.0 is not compatible with the runtime in my project and on Mac M1, there are a lot of issues running multiple dotnet instances..
I guess its a bit of a rock and a hard place, anyone know how I can get around this issue?
This is a recent update to Omnisharp, which is used by the VS Code C# extension. Add this to your settings and restart the editor.
"omnisharp.useModernNet": false,
"omnisharp.path": "",
Also if you don't have Visual Studio installed you will likely need to install the Build Tools to get MSBuild:
My understanding of the rationale behind this change is an optimization for modern vanilla c# projects over those using older versions (ie Unity). More info in this issue.
Revert your Omnisharp to previous version
Update 1.25.0 introduces newer OmniSharp build for .NET 6 which does not support non SDK style .NET projects but results in performance improvements.
Fortunately you can disable this in the settings:
C# Extension Settings
Also, the C# extension no longer ships with an included Mono & MSBuild Tools. Download them here: Build Tools
Worst case, you can revert to an older extension version.
Go to extensions in VS Code and search for C# Extension
VS Code Extensions
Go to C# Extension settings
C# Extension Settings
Disable "Use Modern Net" option.
Modern Net Option
Restart VS Code
I haved similar problem and i fixed like this:
Im using win7 and i have VS 2019 IDE which not supporting dotnet 6 cuz of that vs_installer not installing dotnet6 sdk, in result i cant use c# extension v1.25.0 in vs code, because omnisharp needs net6. I installed net 6 sdk to my win7 and problem is solved, now i can use c# extension v1.25.0 in vs code.
I have a VC++ based application developed in VS2010 which uses some of the win32 component. I ported the code in VS2013 and I built the code after removing all compilation error in Release Mode. Now when I am trying to run the exe in Computer where VS2013 is installed it is working fine where as it is giving an error of mfc120.dll is missing where only VS2010 is installed. I don't think after building the code in Release mode I should get an error of missing dll. I have not tried to run the exe where no Visual Studio is installed.
If you are using the DLL version of the MFC you also need to install the corresponding VS-2013 runtime DLLs vsredist_x86
Or you switch to a complete static build.
I have found out the solution for this problem. Basically the win32 code I was building was using the Configuration Properties->General-> 'Use MFC in a Shared DLL' which I changed to 'Use MFC in a Shared DLL'. All working fine there after
I am learning archicad and trying to open an existing example from API Development Kit in VS Express C++ 2013. I have installed SDK 7.1. in order to 64 development as VS Express doesn't run it by default. I am having trouble to run the example.
However, I installed all the necessary components and programs. This error window pops up all the time I try to run. I really have no clue how to make an archicad sample project run in VS C++ Express 2013.
The third line in Russian is translated as: "Impossible to find the designated folder".
I copied the API DevKit folder into the VS Express folder, doesn't help.
Please, help if someone faced such a problem or does all this stuff.
P.S. I need to run ArchiCAD in VS C++ Express.
This is the print screen:
As a former Archicad API developer, I would definitely recommend you to use Visual Studio 2005 Express.This specific version (assuming you are developing for AC12 and above), is compatible with the API (I developed for AC13 and AC15, it worked fine). That is also recommended by Graphisoft itself.
for further information:
http://www.archicadwiki.com/Developer/Getting%20Started%20with%20the%20API%20DevKit#Getting_Started_with_the_API_DevKit
You have to check the encoding of APIdefs_Automate.h. If it is ANSI, it will fail. The encoding must be UTF-8.
For older archicad projects you had to use vs2010. For the new 21 they upgraded to vs2015. To use vs2015 in older projects you have to have vs2010 installed to use it's v100 platform toolset. Then when you open an older project with the new visual studio, it asks for upgrading the project, here say no and you are good to go.
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.
For someone who's been down this road, please share your breadcrumbs.
I have old VS2005 solution. Most of the parts are c# but I have one c++ managed project. Dev machine: Windows XP. Target framework version: 2.0
I moved the project to the Windows 7 64 BIT, VS 2010, did the project conversion. First thing I noticed were build errors - projects depending on one what is in c++ complained that project referenced has target 4.0 and I want to use it in project that (properly) targets 2.0.
OK, so I used some tips and set my project target to .NET 2.0. NOW: VS2010 complains that it cannot load the project because I need to install framework 2.0. OK, so I try to install it, and nothing - since installer detects .NET 2.0 as a part of the operating system.
WTF?
Admins, please create WTF tag for me here :)
It is not the .NET version that's the problem. The C++ build system currently does not directly support building for pre-.NET 4.0 targets. It requires VS2008 to be installed so it can use its tool chain. Sounds like you don't have it.
This blog post explains the workaround. You can upvote this feedback article if you're unhappy with that. No idea if this is slated to be fixed in SP1, this is not drawing a lot of votes.