I am using ReactJs.NET in a ASP.NET MVC 4 project. I have disabled the fallback to MSIE javascript engine by specifying this in my ReactConfig.cs that is called on app start:
ReactSiteConfiguration.Configuration.SetAllowMsieEngine(false);
This works on my developer machine but not in production. The exception that is thrown is:
Failed to initialise ClearScript V8. This is most likely caused by the native libraries (ClearScriptV8-64.dll and v8-x64.dll) missing from your app's Bin directory, or the Visual C++ runtime not being installed
I have ensured that the ClearScript.V8 folder (with ClearScriptV8-64.dll and v8-x64.dll) is copied across to the production server and the bin folder so I am currently looking at whether the Visual C++ runtime is missing or not. I downloaded and installed the Visual C++ Redistributable for Visual Studio 2015 located here: https://www.microsoft.com/en-us/download/details.aspx?id=48145 but the same exception is thrown.
Is there something obvious I am missing here? Is it the wrong Visual C++ runtime that I have installed?
Are those DLL files in a ClearScript.V8 folder? They need to be at bin\ClearScript.V8\ClearScriptV8-64.dll for example.
Alternatively, you can try out the release candidate of ReactJS.NET 3.0, which uses a newer version of JavaScriptEngineSwitcher that changes how V8 is loaded and no longer requires the DLL files to be manually copied over. There's currently no documentation on ReactJS.NET 3.0 but it's pretty similar to the current 2.x version. I'll be working on the documentation for the final release soon.
In my case I managed to resolve this by installing the Visual C++ 2013 runtime, this was the only version that actually worked in this case. I had no luck with neither 2012 or 2015.
I found the answer here:
https://github.com/reactjs/React.NET/issues/80
and the comment that helped me was:
Just another note, ClearScript 5.4.4 readme says VS2015 or 2013 C++
runtimes will work, but in my experience, it only worked when 2013's
was present.
Related
I have already installed VS2017 Enterprise 15.6.4. Recently installed .NET Core 2.1.101 SDK from official site
I was expecting .NET Core 2.1 as one of the target framework available if I create console or asp.net core application. Can someone help me understanding what I am missing here.
As suggested in comments, I installed 15.7 preview 2. Still no luck and same issue.
I have faced the same problem. I solved this by installing the right SDKs with Runtime for .NET Core 2.1.
Basically to run/create 2.1 projects from VS Preview, you need to install the "2.1.300" (not 2.1.4) .NET Core SDKs and Runtime. https://www.microsoft.com/net/download/dotnet-core/sdk-2.1.300-preview1 (this includes required Runtime already)
The good explanation of this misleading with versions i found here https://github.com/dotnet/cli/issues/8309 (dasMulli commented on Feb 24).
In case this helps someone else... After installing VS 15.9.2 my project that was working fine with 2.2 preview-3 stopped working. VS could not see the preview SDK. I could build the solution using dotnet.exe but not VS.
To solve this I created a global.json at the root folder of this solution pointing to the preview sdk. That allowed VS to see the preview version.
This is a change of behavior in VS between 15.8.x and 15.9.x.
To create the global.json you can navigate to the desired folder and type this:
dotnet new globaljson
Make sure dotnet PATH variables are in correct order
If you have installed an SDK for a different system architecture (e.g., if you installed 32-bit/x86 SDK on a 64-bit computer), then a new entry in the PATH variable would have been created for that specific location (e.g., C:\Program Files\dotnet or C:\Program Files (x86)\dotnet).
The problem is that Visual Studio, when searching for installed frameworks, will stop at the first PATH variable entry it finds that contains an SDK. So, if the first version you installed used an incorrect architecture, then you'll have to adjust the position of those entries before any of the correct SDKs will appear in the Target Framework drop down.
Source: this absurdly-hard-to-find comment within issue #8309.
TL;DR: Make sure the first "C:\Program Files\dotnet\" entry in your path variable you see in the list matches your system architecture:
64-bit = C:\Program Files\dotnet\
32-bit = C:\Program Files (x86)\dotnet\
Make sure that Visual Studio 2017 is up to date. Go to "Tools" -> "Extensions and Updates" to install visual studio updates. This resolved the issue for me.
I have faced the similar situation I tried to install the preview version of the dot net but it did not help.
However after I updated visual studio (from 15.8 to 15.9.6 ).
I Could see dot net core 2.1 in the target framework.
Updated to Latest VS 2017 and installed latest .Net Core SDK.
Changed global.json to point to latest version installed.
This resolved for me.
I had faced the similar issue. I then just updated my Visual Studio 2017 to 15.9.16 version and restarted the system. The problem got resolved.
I was facing the similar issue, I uninstalled the .Net Core 2.2 runtime and then from the below link:
https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral
Install the .Net Core 2.2 Visual Studio SDK, Restarted the Visual Studio and my issue got resolved, .Net Core 2.2 is now getting listed in Target Framework list in the project properties in Visual Studio 2017 Version 15.9.16
I created a new project under .net core 2.1 and it was ok but in my old project have not appeared. So I opened both ".cproject" files and compared them together and found the problem.
Open your project's ".cproject" file in a text editor then replace below line
<TargetFramework>netstandard2.1</TargetFramework>
with this one:
<TargetFramework>netcoreapp2.1</TargetFramework>
I am currently updating a VB.NET application with Visual Studio 2013 that possibly was originally created on VS2010 or VS2012.
This application uses a Network SQL Database
Everything goes fine up to the point of installing when just shows an error message. that says the Assembly 'Microsoft.VisualBasic.Shell.9.0' version 2.0.0.0
is required and then will not let me finish the installation.
The project has been exported using the Visual Basic tool [OneClick]
I have already checked the References list on the Project menu, and is not included there. Also not available to be added.
The project requires the Microsoft Framework 4.5, so it seems that the Shell v2.0.0.0 is pretty old...
Do you have any suggestions, this kept me scratching my head already quite a while...
I finally figured it out.
I am not too sure if this is the right solution or not but it worked for me. Hopefully this will help someone else.
It turn out to be a error with the framework I was compiling the project (v4.5),
I was trying to install it on a Windows 7 machine with a framework installed up to v4.0. I cant understand why this error message showed up instead of telling me the framework version required for the software was not installed.
But anyways, I changed the version on the compiler, build and export again. Another error pop up but it was because references to the DLL for the different framework version were not included in the project. After including them and set the value for "Copy to Local" to true, the installation worked like a charm.
So I got my program up and working.
I tried to change the Target Framework on my app recently from .NET Framework 4.5 to 4.5.2, but if I do I get the following error when trying to build: "'Forms' is not a member of 'Windows'" (that is, System.Windows.Forms). Changing to 4.5.1 works normally. I'm using Visual Studio 2013 Ultimate.
I had this error when changing to 4.5.2.
In my case the error was related to a MessageBox ... I replaced: "Windows.Forms.DialogResult.Yes" (which caused the same error message) with "System.Windows.Forms.DialogResult.Yes" which did the trick.
I had the same problem, me too with Windows.Forms.DialogResult enumeration values.
The project automatically imports System and System.Windows.Forms namespaces and worked fine up to 4.5.1.
In 4.5.2 I had to remove Windows.Forms. and just leave DialogResult.Ok (or whatever else) in my code, it seems to be a problem with namespaces resolution.
Make sure that you add System in front of the Windows.Form.
I ran into this with an application still targeted to .NET 4.0, where it failed on one (new) build server, but ran on my older ones.
I narrowed it down to the .NET 4.0 Targeting Pack only being installed on the old build servers. Targeting pack is included in Visual Studio, or the Windows 7.1 SDK. It is for some reason not distributed separately, and with support ending for .NET 4, 4.5 and 4.5.1, I don't suspect this is likely to change. Because my older servers have been around a couple years, they've gone through in-place upgrades and so had the targeting pack already.
When you install Windows 7.1 SDK on Server 2012R2, it complains something to the effect of "A pre-release version of .NET 4 is installed, please install the RTM version". As far as I can tell, it's simply because a newer version) is installed -- Server 2012R2 comes with 4.5.1. I tried to uninstall all newer versions, but was unable to get the SDK to install the targeting pack.
So to install:
Download the Windows 7.1 SDK ISO image
Unzip it
Run Setup\MTPack\netfx_dtp.msi EXTUI=1
You should now have a %programfiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\ folder with the 4.0 stuff.
(EXTUI=1 bypasses the restriction that it can't be installed separately).
This allowed me to compile projects still targeting 4.0 (or re-build old revisions/branches that were targeting it at the time).
When I try to run the dll I compiled in Visual Studio 2010, I get the following message: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. I'm guessing this means that I am a too recent version of Visual Studio. Is there a way I can build the dll as an earlier version?
All assemblies in your final solution, be they dlls or exes, in different solutions or in the same one, must target the same version of the CLR. You can ensure they do by configuring targeting in your 2010 solution.
Most likely you're targeting 4.0 in your dll's project. Crank it back to 3.5 or earlier and see if that fixes the problem.
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.