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?
Related
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.
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'm struggling with building NLua from source on Windows.
It requires a modified Lua version, otherwise my code fails with a missing "lua52.dll".
https://github.com/NLua/NLua/issues/53
I tried to get it from here
https://github.com/NLua/lua
then used "cmake ." and built the resulting "lua.sln" in visual studio.
What happens is that I get a "lua52d.dll" (note the "d"). If I rename it, a "System.BadImageFormatException" is thrown by "KeraLua" (when I try with some "NLua.exe" executable I found in the "tests" folder of NLua).
Can anybody tell me how to build the modified lua52.dll required by NLua?
I already have a binary that works but need to be able to rebuild everything by myself. Possibly I'm simply using the wrong source tree.
You're using the right source tree, its just that you're compiling the debug version of the dll, not the release version of the dll. The added 'd' is to denote that it is the debug version of the dll, not the release version.
I am running ubuntu 12.04 64 bit, I have set up FB4Linux (FlashBuilder for Linux) and installed the »flash-installer« installer plugin via »apt-get«. I downloaded the latest version of the plugin-debugger from adobe and followed the install instructions from the included README.txt file. Running eclipse (Version: 3.7.2, Build id: I20110613-1736), creating a new as3 project works, build works, everything fine, I can start the debugger and step through the code BUT after a while the debugger just disconnects and stops. No error, no crashes, debug session just over.
Any Ideas?
.log
about:plugins:
Flash - Version: 11.2 r202
Shockwave Flash 11.2 r202
I think , this is happenning more fequently due the enhanced breakpoint listener support in eclipse.When a breakpoint is removed, it is trying to notify its "breakpoint specific" listeners, which were stored in the breakpoint. Of course, this will not work since the underlying marker has been deleted. but things will happen after removing break point. so one way to resolve this problem is to try to un-select
Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions
may this will help you!!
The solution to this issue occurred as side effect after I applied the changes from the answer of this question. When I tried to set the compiler options to target version 11.2, which is actually installed on my system errors occurred because their were files missing in the sdk folder (which are the described changes) and I could only develop for version 11.1. Kind of wired but the update of the sdk made the debugger run stable.