Discussion :

[Danyel]

Salut all et bonnes fetes de fin d'annee.

J'ai un soucis avec le framework quand il n'est pas installe sur la machine qui lance une appli frameworked.
J'ai cherche longtemps sur le net et ici, mais d'apres ce que j'ai pu en lire, il faut creer un code natif (C++ comme vu sur un post de smyley), n'utilisant pas le framework, faire la detection si oui/non et si oui lancer l'application sinon message d'erreur.

Ok pour tout cela, mais si vous avez plus d'info ou explications sur ce code natif et/ou un code explicatif, car n'ayant jamais code C++, c'est assez difficile.
Merci pour votre aide et renseignements.

[lysiandad]

[...] d'apres ce que j'ai pu en lire, il faut creer un code natif (C++ comme vu sur un post de smyley), n'utilisant pas le framework, faire la detection si oui/non et si oui lancer l'application sinon message d'erreur.[...]

Vous pouvez vous en sortir plus simplement en utilisant Windows Scripting Host ; par exemple, pour le FX 2.0 :

( detect_fx20.js ; à exécuter via : C:\>cscript //nologo detect_fx20.js )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
var wsh = WScript.CreateObject("WScript.Shell");
var fx20value = wsh.RegRead("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\.NETFramework\\policy\\v2.0\\50727");
var fx20present = ((fx20value != null) && (fx20value != ""));
if(fx20present)
  WScript.StdOut.WriteLine(".NET framework 2.0 présent");
else
  WScript.StdOut.WriteLine(".NET framework 2.0 absent");
 
if(fx20present)
  wsh.Run("chemin\\votre_appli_dotnet.exe");
else
  WScript.StdOut.WriteLine(".NET framework 2.0 est pré-requis...");

'HTH

[Danyel]

Merci pour l'info et le code, je vais tester tout cela

[Danyel]

J'ai une erreur lors du lancement : Erreur en entree: il n'y a pas de moteur de script pour l'extension de fichier .js

[lysiandad]

J'ai une erreur lors du lancement : Erreur en entree: il n'y a pas de moteur de script pour l'extension de fichier .js

Oh ! My bad... Quel est votre système, alors ?

A priori, avec Windows XP / Server 2003 et plus (pour Windows 2000, je ne suis pas sûr), le Windows Scripting Host arrive "out-of-the-box" avec un support pour .js (JScript / aka JavaScript a la Microsoft), .vbs (VBScript), et .wsc et consoeurs... mais je suppose que "certains" (l'utilisateur et/ou certaines applications, voir p.ex (*), a verifier ce qu'il en est sur votre systeme) peuvent inhiber telle ou unetelle extension...

A toute fin utile, le lien vers le setup du WSH pour XP, p.ex :

http://www.microsoft.com/downloads/d...DisplayLang=en

'HTH

(*) http://assiste.com.free.fr/p/comment...ting_host.html

[Danyel]

Oh ! My bad... Quel est votre système, alors ?

Je suis tout simplement sous Vista SP1.
Enfin, ce probleme releve que c'est une solution peu satisfaisante pour mon cas, car l'appli doit pouvoir tourner sous toutes versions de windows, et ca inclus donc cette fameuse detection (et sans que ce soit une calvaire pour les utilisateurs )

Sinon merci pour les infos que je vais lire avec attention.

D'autres solutions ... ?

[lysiandad]

Alors, oui, une solution possible sera d'ecrire un "wrapper" natif pour detecter le framework puis, si celui ci est present dans la "bonne version" pour votre application, charger dynamiquement le runtime (CLR) et invoquer votre point d'entree dans un de vos assembly (ou qui deleguera a un autre .exe en mode géré de votre application).

Je n'ai pas encore testé la technique, bien sûr prévue par l'architecture .NET dès la version 1.0 (je n'ai donc pas encore de code a vous proposer, mais je vais probablement m'y essayer par curiosité), en revanche, sur ce "CLR hosting", nous avons a priori au moins une autre bonne ressource a coté de la doc du framework lui-même (*), là par exemple :

http://community.bartdesmet.net/blog...g/default.aspx

(cf. la serie d'article sur le "CLR hosting" proprement dit ; les parties 1 et 2 plus particulierement, pour le probleme qui nous interesse)

'HTH

ps :

(*) (liens pertinents vers la doc MSDN) :

* http://msdn.microsoft.com/fr-fr/library/ms164408.aspx

* http://msdn.microsoft.com/en-us/libr...yh(VS.71).aspx

[ EDIT ]

pps :

il nous faudra peut etre ecrire du code avec liaison "différée" aux APIs de hosting CLR (plutot que "statique" via l'usage de .lib(s) par le linker C/C++), en utilisant le classique LoadLibrary (Win32) et/ou CoGetClassObject (COM) ; dès lors que nous faisons l'hypothèse que nous ne savons même pas, a priori, si le support natif Win32 et COM pour le runtime .NET est a minima présent (puisqu'il vient avec le framework, précisément) ; mais ce point est vraisemblablement adressé par la serie d'articles ci dessus, à vérifier

[smyley]

Si tu te limites au .NET Framework 2.0, il suffit de vérifier l'existence et la version de C:\Windows\System32\mscoree.dll
Si tu veux vérifier les Service Pack ou les versions 3.0 - 3.5, c'est plus chaud ... mais dans tout les cas, le pire à faire c'est tester l'existence de clefs du registre, pas passer par des choses bizarres de CLR Hosting ou transmutation alchimiste du plomb en or ...

[Danyel]

Si tu te limites au .NET Framework 2.0, il suffit de vérifier l'existence et la version de C:\Windows\System32\mscoree.dll

Effectivement, c'est une excellente idee.
J'ai reellement juste besoin de savoir si le framework vX est installe sans aller chercher dans les details.

Il est quand meme peu convivial qu'il n'y ait pas une detection (simple et automatique) lors du lancement d'une appli frameworked, qui laisse l'utilisateur dans l'attente de qq chose, sans qu'il sache qu'il ne se passera rien s'il ne l'a pas.

Allez bonne et excellente nouvelle annee 2009

[smyley]

J'ai reellement juste besoin de savoir si le framework vX est installe sans aller chercher dans les details.

A partir du framework 2.0, tu peut regarder ici :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP

[Danyel]

Oui le controle de la bdr doit etre la meilleure solution, mais le probleme c'est la creation du code natif.
(quoi que ca doit pas etre tres complique meme avec un langage non connu)

[lysiandad]

[...]pas passer par des choses bizarres de CLR Hosting ou transmutation alchimiste du plomb en or ...

Bof, "l'alchimie" se revele ne pas etre si inaccessible que ça, en fait :

VS2008 -> File -> New Project -> Visual C# -> Class Library :

(MyClass.cs)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace MyNamespace
{
    public class MyClass
    {
        public static int Probe(string cookie)
        {
            return int.Parse(cookie);
        }
    }
}

Puis :

VS2008 -> File -> New Project -> Visual C++ -> Win32 Console Application :

(clrhosting.cpp)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
// clrhosting.cpp : Defines the entry point for the console application.
//
 
#include "stdafx.h"
#include <windows.h>
#include <mscoree.h>
 
typedef HRESULT (FAR WINAPI *binder)(LPCWSTR pwszVersion, LPCWSTR pwszBuildFlavor, REFCLSID rclsid, REFIID riid, LPVOID FAR *ppv);
 
int _tmain(int argc, _TCHAR* argv[])
{
	ICLRRuntimeHost *host = NULL;
 	HMODULE mscoree = NULL;
	binder Api_CorBindToRuntime = NULL;
	mscoree = LoadLibrary(L"mscoree.dll");
	if(mscoree != NULL)
	{
		Api_CorBindToRuntime = (binder)GetProcAddress(mscoree, "CorBindToRuntime");
		if(Api_CorBindToRuntime != NULL)
		{
			if(Api_CorBindToRuntime(L"v2.0.50727", L"wks", CLSID_CLRRuntimeHost, IID_ICLRRuntimeHost, (LPVOID*)&host) == S_OK)
			{
				HRESULT hr = S_OK;
				DWORD returnValue = 0;
				host->Start();
				if(((hr = host->ExecuteInDefaultAppDomain(
					L"d:\\poc\\clrhosting\\managed\\bin\\debug\\managed.dll",
					L"MyNamespace.MyClass",
					L"Probe",
					L"1234567890",
					&returnValue)) == S_OK) &&
					(returnValue == 1234567890))
					printf("Probing OK : .NET framework installed & working properly");
				else
					printf("ExecuteInDefaultAppDomain error : hr == %d ; returnValue == %d", hr, returnValue);
				host->Release();
			}
			else
				printf("CorBindToRuntime error : version of .NET framework not found");
		}
		else
			printf("GetProcAddress(\"CorBindToRuntime\") error");
	}
	else
		printf("LoadLibrary(\"mscoree.dll\") error : none of .NET framework versions is installed");
	return 0;
}

Avec un tel mecanisme, depuis notre code natif, on a une meilleure garantie :

* de vérifier que le framework .NET est bien installé
* si oui, que c'est "la bonne version" pour notre code managé que l'on envisage d'executer
* enfin, que le chargement de notre code managé en question se passe bien, a priori, avant de tenter d'executer le reste notre application .NET complète

'HTH

[Danyel]

A premiere vue, ton code a l'air correct, mais sans connaitre le C, c'est plus complique
Deplus, ne pas utiliser le mode console, mais afficher une belle petite fenetre, c'est plus convivial.
Je vais voir tout cela plus en profondeur, car il faut deja imaginer que la version du frmaework peut changer et evoluer, donc faire en sorte que ca ne bloque pas comme actuellement.

Par contre si tu peux m'expliquer ton (MyClass.cs) ... j'ai du mal a comprendre son utilite.
Un grand merci à toi.

[smyley]

Bof, "l'alchimie" se revele ne pas etre si inaccessible que ça

Donc oui, pour vérifier la version du framework, tu charges un framework version 2.0 sans même savoir ce que c'est, tu charge une assembly, tu l'exécutes et t'es content si ça marche.
De fait, tu ne peut pas faire la différence entre le .NET 2.0 et le .NET 3.0 vu que le CLR est le même. Idem, tu dois te battres pour avoir les versions exactes des framework à charger (quelle est la version du .NET 2.0 SP1 ? 3.5 SP1 ? 3.5 ?).
La méthode recommandée par Microsoft, du moins tout ce que j'ai eu l'occasion de voir, c'est de passer par la clef de registre ***\NDP qui offre un moyen simple d'avoir la version exacte du framework (sous clef 3.5 par exemple), qui contient un champ qui peut informer du service pack actuel et également des sous clefs qui peuvent permettre de savoir si WPF, WCF, etc. sont bien installées. Je reste sur ma position que ma méthode est la meilleur.

[lysiandad]

De fait, tu ne peut pas faire la différence entre le .NET 2.0 et le .NET 3.0 vu que le CLR est le même. Idem, tu dois te battres pour avoir les versions exactes des framework à charger (quelle est la version du .NET 2.0 SP1 ? 3.5 SP1 ? 3.5 ?).
La méthode recommandée par Microsoft, du moins tout ce que j'ai eu l'occasion de voir, c'est de passer par la clef de registre ***\NDP

Ben, rien n'empeche Danyel d'inspecter d'abord cette clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP pour connaitre la version exacte installée du framework, oui, c'est une très bonne idée, mais egalement d'executer mon code pour verifier que le CLR sous-jacent de ce framework (1.0 ou 2.0 etc) est effectivement présent et opérationnel.

Je reste sur ma position que ma méthode est la meilleur.

En repondant sur cette discussion, j'etais moins preoccupé à trouver la methode "la meilleure" (suivants quels criteres, au fait ? cela aurait dû etre mis en avant dans la formulation du problème, non ?) que de trouver une methode, a minima, raisonnablement fiable.

Moi aussi, je conviens tres volontiers que d'inspecter telle ou telle information de signature d'installation dans la base de registre est une methode souvent simple et tout à fait efficace, et c'est d'ailleurs dans ce sens que j'ai d'abord repondu, sauf erreur de ma mémoire, puis, suite a reponse de Danyel, j'ai interpreter son besoin comme etant ré-orienté de façon legerement differente : d'avoir un bout de code natif capable de s'executer "n'importe où" (avec ou sans le FX, avec ou sans Windows Scripting Host qui semble l'ennuyer) pour determiner si le FX est present et operationnel sur la machine.

La meilleure methode est sans doute donc la votre, si par meilleure on entend simplicité d'ecriture et fonctionnalité.

Je n'ai fait qu'en proposer une autre, legerement plus compliquée (mais loin d'etre hors de portée, amha) qui a un interet complementaire a la votre en fait : car "n'importe qui" peut ecrire dans la base de registre sous HKLM\..., premier point, ensuite, meme si c'est "le vrai framework, vraiment installé" qui est cité par cette information "déclarative" que nous lisons dans la bdr, cette dernière information, pour le code applicatif managé de Danyel ne va pas lui dire, par exemple, si du code managé non-Microsoft requis par son application est également inscrit dans la GAC et opérationnel ou si d'autres libs tierces requises sont installées et accessibles... avec mon mecanisme de "probing" relativement simple, qui justement contient du code managé (méthode Probe), Danyel pourra verifier (a) que le framework pour la version qui l'interesse (via ...\NDP) est effectivement executable, et (b) que son code managé peut trouver un environnement managé nécessaire (a défaut d'etre suffisant) pour son execution.

Bah, il ne manquera pas de choisir / adapter ce qu'il lui convient le mieux je suppose, et quant à moi, je considère que j'ai investigué suffisamment un des éléments que j'avais annoncé. Je vais donc m'arreter là.

Bonne année à tous, au fait

'HTH

[lysiandad]

[...]Par contre si tu peux m'expliquer ton (MyClass.cs) ... j'ai du mal a comprendre son utilite.
Un grand merci à toi.

L'utilité est la suivante :

vous commencez donc par executer du code natif (ce bout de code en C/C++, donc, qqpart dans une appli console ou Windows, peu importe) ; puis, pour verifier si le FX est present vous inspectez la clé bdr indiquée par smyley (...\NDP) et, si la bdr vous dit "le bon FX est là", comme St Thomas, vous ne voulez croire que ce que vous voyez :

donc, vous faites en sorte d'"heberger" le runtime (CorBindToRuntime, ICLRRuntimeHost, etc), puis vous le demarrez, et enfin, vous chargez dans l'AppDomain par defaut du process courant un de vos assemblies pour faire le probing que cette version du FX convient a votre code VB.NET (ou C#), etc, car rien ne vous empeche ainsi, au passage, dans cette methode Probe() qui est triviale dans mon exemple, d'executer du code managé quelconque mais plus intéressant / pertinent pour votre application, en gerant telles ou telles exceptions, pour savoir si telle ou telle librairie tierce .NET est elle aussi présente en plus de la présence du bon framework pour votre besoin...

'HTH

[smyley]

La meilleure methode est sans doute donc la votre, si par meilleure on entend simplicité d'ecriture et fonctionnalité.

Le truc c'est qu'il n'est pas sur que ça marche. Si cela est fait dans un but de vérifier la disponibilité du framework, qui garentit que les assemblies System.Windows.Forms et compagnie sont bien présentes (sauf si un crash survient). Et de plus, si n'importe qui peut écrire dans la base de registre, n'importe qui aussi peut modifier les fichiers d'un framework quelconque (vu qu'il y a le même niveau de sécurité pour HKLM et les fichiers de C:\Windows). Et pour vérifier que d'autres composants complémentaires sont présents, il faut le vérifier justement, pas lancer l'application en regardant si ça crash (comment savoir dans quel état l'application à laissé l'ordinateur cible lors d'un crash ? le but c'est justement de ne jamais en rencontrer et de tout gérer de manière à l'éviter).

Si on a une application qui utilise par exemple WPF et WCF, on vérifie que .NET 3.0 est installé, ou alors on vérifie .NET 2.0 + WPF + WCF, toutes ces informations étant accessibles via la version de mscoree.dll et les clefs de NDP.

Et de plus, croire le registre n'est pas se fier à n'importe quoi, vu que Windows lui même se base dessus. Si on admet que l'on peut écrire des informations erronées dans le registre là où il ne le faut pas, il faut aussi admettre que l'on puisse modifier les fichiers systèmes de manière abérante et dans ce cas rien n'est sur. Ce n'est pas parce que c'est le registre que c'est moins fiable que le système de fichiers ou les services installés ou les objets COM présents (qui sont, entre autres, enregistrés dans le registre ...).

[Danyel]

Effectivement, vos 2 visions sont complementaires et toutes ses infos sont des plus interessantes et instructives.
Je vais en premier lieu me baser sur le controle dans la bdr et faire une verification sur la dll.

Un grand merci à vous 2.