I cannot for the life of me get F# to run in Visual Studio Code. I've had it up and running previously, but not with the most recent versions of the software.
I installed the most recent versions of .NET and VS code a month ago and again now, did full deletes and re-installs both times (including deleting user/.vscode and roaming/Code manually), but the error persists.
I am on a Windows 10 and have installed x64 versions of .NET Core 3.1 and VS Code 1.48 with the only extensions C# 1.23 and Ionide-fsharp 4.16. I have enabled Use Sdk Scripts for ionide, but otherwise run on default configuration. dotnet fsi is executed without problems in the command line.
Looking at the VSC extension host log:
[2020-08-15 11:24:35.431] [exthost] [error] Error: Language client is not ready yet
at LanguageClient.sendRequest (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:7887:19)
at __exports.compilerLocation (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4290:19)
at fsacConfig (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4730:12)
at c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4797:20
at Object.__exports.msbuild (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4802:10)
at activate (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:19152:91)
at c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:25116:90
which I believe is caused by this problem seen in the VSC F# log:
[Error - 11.24.35] Starting client failed
Launching server using command Invalid macro definition. failed.
I'm stuck here as I don't know what macro definition this refers to or how to get more information about the failure.
I just found the cause and solution for the problem. It had nothing to do with Ionide or Visual Studio Code. Instead my cmd was acting up due to misconfiguration.
For a while the message "Invalid macro definition" has been output as the first thing when I open cmd, but I didn't see the connection to the problem above. Turns out that VS code did not like this output and that it was the AutoRun configuration for cmd that triggered this error.
Using regedit, I found that I had several AutoRun files that were no good, so I removed them from respectively Computer\HKEY_CURRENT_USER\Software\Microsoft\Command Processor and Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor and the problem was solved.
Related
I'm working at a visual effects studio in which we use MongoDB/pymongo for our asset management. Our studio is using the SideFX software Houdini.
So far MongoDB has been a pleasure to work with in terms of programming, however whenever we connect to the MongoDB via pymongo from within Houdini, we're getting the following error:
Microsoft Visual C++ Runtime Library - Runtime Error!
Program: C:\houdini\17.5.293\bin\houdini.exe
R6034
An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.
This error occurs everytime when we import pymongo for the very first time, i.e. in a Python shell within Houdini, which is using Python 2.7. Once we click 'OK' on the error popup (it appears twice after clicking OK for the first time), the error disappears and we're able to connect successfully to the database.
The SideFX support team suggested that pymongo wasn't compiled with Visual Studio 2017, which is the compiler SideFX is using for their software.
Now we've been trying to debug this for a while now to no avail. Here's a rundown of what we tried:
update Windows10 to the latest and greatest
updating pymongo from 3.5.1 to 3.9.0
launching Houdini from different builds (16.5, 17.0, 17.5), we get the error in every version.(We're launching a vanilla Houdini session without any 'PYTHONPATH' or 'PATH' environment variables set)
interestingly enough my colleague imported pymongo into Houdini successfully on his private laptop last night without any errors occurring which leads me to believe that the error might be related to our system settings possibly?
I would love to find out how to get rid of this error message because it is really messing with our current pipeline. Any suggestions/help is welcome and much appreciated.
Please let me know if you need any additional information in order to debug this matter.
Thanks a lot in advance,
Manu
This post here helped me to resolve my issue:
Runtime error R6034 in embedded Python application
What happened is that we have a Python 2.7 install located at C:\Python27 which is being added as an environment variable 'path' in Windows.
Using the Process Explorer, I learned that this folder contains the file 'msvcr90.dll' which is conflicting with Houdini, since Houdini comes with its own Python installation that doesn't contain this dll file.
The solution is simple. When launching Houdini in a custom environment, strip the C:\Python27 from the 'path' environment variable so Houdini only fires up its own Python interpreter.
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I am trying to run a .NET Core version 1.1 application from inside VS Code version 1.8.1. When I push the F5 button, the console appears at the bottom of the screen. After enabling tracing, I get this output:
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[.]... Considering fxr version=[..]...
Considering fxr version=[1.1.0]... Detected latest fxr
version=[C:\Program Files\dotnet\host\fxr\1.1.0]... Resolved fxr
[C:\Program Files\dotnet\host\fxr\1.1.0\hostfxr.dll]... Loaded library
from C:\Program Files\dotnet\host\fxr\1.1.0\hostfxr.dll Tracing
enabled
--- Invoked hostfxr [commit hash: 928f77c4bc3f49d892459992fb6e1d5542cb5e86] main Own DLL
path=[C:\Program Files\dotnet\dotnet.dll] Checking if CoreCLR path
exists=[C:\Program Files\dotnet\coreclr.dll] Detecting mode... CoreCLR
present in own dir [C:\Program Files\dotnet] and checking if
[dotnet.deps.json] file present=[0]
--- Executing in split/FX mode... Detected a non-standalone application, expecting app.dll to execute. Application 'build' is not
a managed executable.
Also, a bar appears at the top of the screen that says:
The preLaunchTask 'build' terminated with exit code 2147516564.
When I click the "show problems" option, a blank problems tab appears that contains the message:
No problems have been detected in the workspace so far.
Why is VS Code refusing the build the project, and why are there no problem messages? I am only posting this on SO, because Google was not helpful, and because the VS Code GitHub page recommends asking questions here first.
UPDATE
This problem was caused by me having put coreclr.dll in C:\Program Files\dotnet. I did this, because of a different problem related to building the app. I thought that, since the output mentions it is looking in this directory, it might be helpful to put this file here. It turns out that this was a very bad idea, as it just complicated the problem! LOL!
You can get this error if you have problems in:
packages - please check if all packages are ok and restored successfully
core version - check that core installed with correct version
.net tools - please check if version of .net tools correct.
Can you try visual studio?
http://docs.asp.net/en/latest/tutorials/your-first-mac-aspnet.html
Installed Node
Installed Yo
yo aspent
pick the web application
dnu update
dun build failed with spectacular 2400 odd errors
open the vsCode as we can issue a command on the top that did not work failed and complained omni sharp is not working.
dun went with beta version 1.0.0.4
some where i saw depends on mono downloaded mono installed it.
re-open VSCode and still fails to run with the following error message
error from the vscode
[INFO] Starting OmniSharp at '/Users/bvn/TestApplication'...
[INFO] Started OmniSharp from '/Users/bvn/Downloads/Visual Studio
Code.app/Contents/Resources/app/extensions/jrieken.vscode-omnisharp/bin/omnisharp'
with process id 2775...
[INFORMATION:OmniSharp.Startup] Omnisharp server running using stdio
at location '/Users/bvn/TestApplication' on host 2765.
[INFORMATION:OmniSharp.Dnx.DnxPaths] Using runtime
'/Users/bvn/.dnx/runtimes/dnx-mono.1.0.0-rc1-update1'.
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Scanning
'/Users/bvn/TestApplication' for DNX projects
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Found project
'/Users/bvn/TestApplication/project.json'.
[INFORMATION:OmniSharp.Dnx.DesignTimeHostManager] Listening on port
57325
[INFORMATION:OmniSharp.Dnx.DesignTimeHostManager] Process ID 2784
[ERROR:OmniSharp.Dnx.DesignTimeHostManager] Failed to launch
DesignTimeHost in a timely fashion.
[ERROR] Error: Failed to start OmniSharp
[INFORMATION:OmniSharp.Dnx.DesignTimeHostManager] Client accepted
127.0.0.1:57325
Here is how I manually installed OmniSharp into VS Code. I used the steps in this link to help point me in the right direction. After some tinkering, I got everything working in both OmniSharp within VS Code and the dotnet core debugger integration. The link above implicitly suggests putting files in the .bin\omnisharp\ folder (note the . prefixing bin) but, that didn't work... it worked when I put files in the bin\omnisharp\ folder.
I'm running Windows 10 64bit and .Net Core SDK/CLI v1.0.4 with VSCode v1.14.2. Here are the steps:
Install OmniSharp in VSCode and then close VSCode
If it does not already exist, create bin\omnisharp and .debugger folders under %userprofile%\.vscode\extensions\ms-vscode.csharp-1.11.0\
In the runtimeDependencies section of this packages.json, download the zip files for OmniSharp (.NET 4.6 / x64) and for .NET Core Debugger (Windows / x64)
Unzip omnisharp-win-x64-<version>.zip into %userprofile%\.vscode\extensions\ms-vscode.csharp-1.11.0\bin\omnisharp\
Unzip coreclr-debug-win7-x64.zip into %userprofile%\.vscode\extensions\ms-vscode.csharp-1.11.0\.debugger\
Launch VSCode and run thru a simple Hello World dotnet core example... everything should work.
I hope the info helps. :)
The problem I need to be solved is that the Nuget Package Manager Console in Visual Studio 2013 cannot start because the Windows Powershell raises the error:
The shell cannot be started. A failure occurred during initialization: The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.
I tried reinstalling nuget, repairing VS2013, changing the execution policy in powershell x86 (the common solution given here in stackoverflow) but the error persists.
Until I realize that the problem is in the x64 powershell(C:\Windows\SysWOW64\WindowsPowerShell\v1.0) because the x86 version is fine.
I'm using Visual Studio Ultimate 2013 Update 4 32-Bits in Windows 8.1 x64
I found out the answer, it has to do with the legacy security policy in .Net
I open the file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config and set the attribute "enabled" to False in the tag NetFx40_LegacySecurityPolicy and voilá, the powershell of SysWoW64 is working.
In my case I was receiving this same error for an unknown reason and thanks to this hint I looked for the NetFx40_LegacySecurityPolicy in
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
and
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
but could not find that tag...
I did see LegacyCasPolicy enabled="true" in
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
and set it to false...viola, worked like a charm...Had no idea of how this got set but could not find a solution to this problem anywhere, and no, I did not have any corrupted system files.
Same issue different key.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
Change to false
NetFx40_LegacySecurityPolicy enabled="true"