Je sais que ce n'est pas idéal, mais ma contrainte est que j'ai une application héritée écrite en Clipper.Comment lancer une application WPF à partir de command.com. Je reçois une erreur FontCache
Je veux lancer un nouveau WinForms/WPF demande à l'intérieur de l'application (pour faciliter la transition). Cette application héritée écrite dans Clipper lance à l'aide:
SwpRunCmd("C:\MyApp\MyBat.bat",0)
Le fichier de commandes contient quelque chose comme cette commande:
C:\PROGRA~1\INTERN~1\iexplore "http://QASVR/MyApp/AppWin/MyCompany.MyApp.AppWin.application#MyCompany.MyApp.AppWin.application"
Il lance un WinForms/WPF application qui est que nous déployons via ClickOnce. Tout s'est bien passé jusqu'à ce que nous introduisions WPF dans l'application. Nous avons été en mesure de lancer facilement à partir de l'application héritée.
Depuis que nous avons introduit WPF, cependant, nous avons le comportement suivant. Si nous lançons d'abord via l'application Clipper, nous recevons une exception lors du lancement de l'application. Le texte d'erreur est:
The type initializer for 'System.Windows.FrameworkElement' threw an exception.
at System.Windows.FrameworkElement..ctor()
at System.Windows.Controls.Panel..ctor()
at System.Windows.Controls.DockPanel..ctor()
at System.Windows.Forms.Integration.AvalonAdapter..ctor(ElementHost hostControl)
at System.Windows.Forms.Integration.ElementHost..ctor()
at MyCompany.MyApp.AppWin.Main.InitializeComponent()
at MyCompany.MyApp.AppWin.Main..ctor(String[] args)
at MyCompany.MyApp.AppWin.Program.Main(String[] args)
The type initializer for 'System.Windows.Documents.TextElement' threw an exception.
at System.Windows.FrameworkElement..cctor()
The type initializer for 'System.Windows.Media.FontFamily' threw an exception.
at System.Windows.Media.FontFamily..ctor(String familyName)
at System.Windows.SystemFonts.get_MessageFontFamily()
at System.Windows.Documents.TextElement..cctor()
The type initializer for 'MS.Internal.FontCache.Util' threw an exception.
at MS.Internal.FontCache.Util.get_WindowsFontsUriObject()
at System.Windows.Media.FontFamily.PreCreateDefaultFamilyCollection()
at System.Windows.Media.FontFamily..cctor()
Invalid URI: The format of the URI could not be determined.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind)
at MS.Internal.FontCache.Util..cctor()
Si nous lançons l'application via l'URL (dans IE) ou via l'icône sur le bureau d'abord, nous ne recevons pas l'exception et de l'application est lancée comme prévu. La seule chose intéressante est que tout ce que nous lancerons avec le premier détermine si l'application sera lancée. Donc, si nous démarrons avec l'héritage en premier, cela casse tout de suite et nous ne pouvons pas lancer l'application même si nous lançons avec l'URL ou l'icône par ailleurs réussie. Pour que cela fonctionne, nous devons nous déconnecter et nous reconnecter et le démarrer à partir de l'URL ou de l'icône.
Si nous utilisons d'abord l'URL ou l'icône, nous avons aucun problème le lancement de l'application héritée de ce point avant (jusqu'à ce que nous et revenir LOGOUT in). Une autre information est que nous sommes capables de simuler le problème de la façon suivante. Si nous entrons dans une invite de commande en utilisant "cmd.exe" et exécutons une instruction pour lancer à partir d'une URL, nous avons réussi. Si, cependant, nous entrons dans une invite de commande en utilisant "command.com" et nous exécutons cette même déclaration, nous éprouvons le comportement de rupture.
Nous supposons qu'il est parce que l'application héritée Clipper utilise l'équivalent de command.com pour créer la coquille pour se reproduire l'autre application. Nous avons essayé un tas de hacks comme avoir command.com exécuter cmd.exe ou psexec et puis l'exécution, mais rien ne semble fonctionner. Nous avons quelques idées de solutions de contournement (comme le lancement de l'application au démarrage, nous forçons le lancement réussi d'une URL, ce qui rend tous les lancements ultérieurs réussis), mais ils sont tous sous-optimaux même si nous avons beaucoup de contrôle sur nos postes de travail.
Pour réduire les risques que cela est lié aux autorisations, nous avons donné le compte lancer des droits d'administration (ainsi que des droits non administratifs en cas qui ont fait une différence).
Toutes les idées seraient grandement appréciées. Comme je l'ai dit, nous avons un peu de travail, mais j'aimerais les éviter.
Merci!
Je vais demander une question stupide Quelle version de .NET Framework fait votre application t arget, et cette version est-elle installée sur l'ordinateur client? – RobinDotNet
Le cadre est .NET 3.5 SP1. Il est installé sur le client. De plus, l'application fonctionne bien si nous la démarrons dans le bon ordre (c'est-à-dire directement au lieu de via legacy) et tout fonctionne exactement comme prévu. – jttraino