|Anonymous | Login | Signup for a new account||2019-06-19 08:11 CEST|
|Main | My View | View Issues | Change Log | Roadmap | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0006670||[JEDI Code Library] Installation||minor||always||2019-04-05 06:47||2019-05-29 14:08|
|Summary||0006670: Problems with .NET Framework 3.5 (JCL3.1)|
I tried to install the JEDI Code Library 3.1 over the GetIt-Package-Manager (Delphi 10.3) on Windows 10 Pro. As first step the JCL installer started the installation of the .NET Framework 3.5, but the .NET Framework installer stopped with the error code “0x800700C1”. I don’t know why, but I am not able to install the .NET Framework 3.5 on my Windows 10 Pro. The Windows-Feature list is always empty and I can’t activate the .NET in the Windows-Features.
Is there a possibility to stop using the .NET Framework 3.5?
|Tags||No tags attached.|
|Fixed in revision|
|Attached Files||JCL_Net.PNG [^] (166,711 bytes) 2019-05-12 08:57|
When I installed JCL a few weeks ago I had the same issue that it required .NET 3.5 framework. I didn't have installation issues with installing .NET framework then (in contrast to Robert), but I too would like to know why JCL needs .net framework.
I thought Delphi .net support is already removed from JEDI nowadays?
I tried to find out where the JCL installer is using .NET but failed so far. JCL does contain various references to .NET in its code, like classes for interacting with it and also a unit for MSBuild usage, which is build using .NET, but even if the JCL installer is using MSBuild to compile (explicitely or implicitely, I only saw references to DCC32 in the install.bat file, so use of MSBuild would be implicit) that shouldn't require .NET 3.5 framework if a newer is on the computer I guess.
Anybody any hints why the installer requires .NET 3.5 framework?
In a post from 6th May in JCL newsgroup (http://newsportal.delphi-jedi.org/thread_frameset.php?group=jedi.jcl) [^] obones suggested, that this .NET requirement comes from getting JCL via GetIt instead of GitHub directly.
Has anybody a Windows 10 VM at hand where .NET 3.5 framework is not installed yet but some Delphi installation (e.g. 10.1 or newer)? And can this person test what happens if he tries to install JCL the traditional way? (downloading the ZIP file from GitHub, extract it, fetch the JEDI.inc and KYLIX.inc files and put them where they belong and then run install.bat).
Does this traditional way also call for .NET 3.5 framework?
Or does any other installation via GetIt (like ICS) call for .NET 3.5 framework?
Comment of Eivind Bakkestuen in the JCL newsgroup about this matter:
"I don't think it does. Removing .NET 3.5 from a VM with 10.3 Rio
triggers the OS "download and install this feature" dialog at the point
where the JCL installer exe attempts to start (so, after GetIt
displays, finds JCL, downloads and compiles it).
The JCL installer exe bombs with
"Exception EOleSysError in module rtl260.bpl at 00574361.
OLE error 80131700."
Trying other installer exe's that start from GetIt does not trigger the
missing .NET feature dialog."
I tried to install it in a new Win 10 VM now and on purpose I did not install .NET 3.5 prior to installation of JCL. When clicking the install button in JCL I got what you can see in the attached screenshot.
=> it IS clear now, that it's a JCL installer problem, as the installation was from a Git repo clone and not from GetIt.
Where to start investigating this? What does JCL installer do which requires OLE?
Ok, in the newsgroup Eivind Bakkestuen posted this valuable information:
"As part of MSBUILD support, the installer ends up calling
TJclClrHost.CorSystemDirectory in jclDotNet.pas, which calls the API
function GetCORSystemDirectory, which appears to not exist in .NET4.x
Probably the JclDotNet unit needs an update to support .NET 4. Sorry,
that's as far as I can take it.
Can you guys tell me how the installer behaves when .Net 3.5 is not installed?
I mean, not from getit, but right from the Git sources.
Does it output a nice message? Does it crash?
I have a potential fix, but I'd like to be sure what happens first.
Here is a transcript of my findings as posted in the newsgroups:
The installer parses the default "msbuild" files that define various locations for the IDE. Do to so, it uses TJclMsbuildParser which in turn uses TJclClrHost.GetClrVersions which calls GetCORSystemDirectory
As it is deprecated, the code should be changed to first call CLRCreateInstance  to retrieve a ICLRMetaHost  instance.
Then on this instance, it should call EnumerateInstalledRuntimes  which returns the collection of ICLRRuntimeInfo  instances.
And each instance in this collection has the GetRuntime  method that is the function that supersedes GetCORSystemDirectory
But then there's the question as to which instance we should use in the collection. The first one? The last one?
 https://docs.microsoft.com/fr-fr/dotnet/framework/unmanaged-api/hosting/clrcreateinstance-function [^]
 https://docs.microsoft.com/fr-fr/dotnet/framework/unmanaged-api/hosting/iclrmetahost-interface [^]
 https://docs.microsoft.com/fr-fr/dotnet/framework/unmanaged-api/hosting/iclrmetahost-enumerateinstalledruntimes-method [^]
 https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/hosting/iclrruntimeinfo-interface [^]
 https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/hosting/iclrruntimeinfo-getruntimedirectory-method [^]
|This is now fixed in GIT|
|2019-04-05 06:47||dr_robert||New Issue|
|2019-04-05 06:47||dr_robert||IDE version||=> All|
|2019-04-13 07:46||mh||Note Added: 0021655|
|2019-04-13 10:49||mh||Note Added: 0021662|
|2019-05-07 22:39||mh||Note Added: 0021816|
|2019-05-08 17:22||mh||Note Added: 0021817|
|2019-05-12 08:57||mh||File Added: JCL_Net.PNG|
|2019-05-12 08:59||mh||Note Added: 0021823|
|2019-05-12 09:07||mh||Note Added: 0021824|
|2019-05-29 10:13||obones||Note Added: 0021852|
|2019-05-29 14:08||obones||Note Added: 0021853|
|2019-05-29 14:08||obones||Status||new => resolved|
|2019-05-29 14:08||obones||Fixed in Version||=> Version 2.5 (Subversion repository/Daily zips)|
|2019-05-29 14:08||obones||Resolution||open => fixed|
|2019-05-29 14:08||obones||Assigned To||=> obones|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|