Runtime: Application console autonome unique exe

Ce scénario n'est pas pris en charge pour le moment. Gardez un œil sur le référentiel https://github.com/dotnet/corert pour les travaux qui mèneront sur cette voie.

CoreRT est le bon endroit pour rechercher cette solution.

Merci. Il semble que CoreRT soit exactement ce que je recherchais.

Pour d'autres qui pourraient trébucher là-dessus, lisez ici

Je veux spécifiquement cette fonctionnalité sans compilation préalable. Je ne veux pas de corert - je veux la même expérience de jit, de débogage et d'exécution qu'une application autonome normale - mais je ne veux pas non plus distribuer quatre fichiers par utilitaire. Ce n'est pas pratique pour quiconque souhaite utiliser l'utilitaire. Je veux juste qu'il soit emballé et exécuté à partir d'un seul exe. Cela me pousse à choisir .NET Framework sur .NET Core pour de nombreux utilitaires.

.NET Framework est «triche» car vous avez déjà beaucoup de fichiers présents dans le système d'exploitation.
Vous pouvez obtenir la même chose avec .NET Core, en installant .NET Core partagé à l'échelle de l'ordinateur si c'est ce que vous voulez.

Refactoriser CoreCLR pour fusionner tous ses fichiers en un seul (y compris natif + géré) n'est pas un travail trivial et je ne pense pas que le scénario soit aussi intéressant pour trop de clients.

La différence est que chaque machine Windows est garantie d'avoir .NET Framework mais pas .NET Core, donc à moins qu'il n'y ait une raison particulière qui vaut la peine de rendre le déploiement plus complexe, je suppose que je finirai par y rester.
Je suppose que les clients n'écrivent généralement pas des utilitaires exe uniques. Peut-être un jour. :-)

sauf s'il y a une raison particulière qui vaut la peine de rendre le déploiement plus complexe

Il y a BEAUCOUP de raisons de préférer .NET Core à .NET Framework. Performances, modularité, facilité d'entretien, isolation, etc. Et cela ne tient pas compte de la multiplate-forme.

Avoir un seul utilitaire exe est principalement une préoccupation esthétique. Il n'y a pas de réelle différence fonctionnelle (pour toute personne impliquée) si l'exécutable est un seul fichier ou un seul dossier contenant une poignée de fichiers.

@mellinoe Oh je suis d'accord pour les projets en général, c'est certainement vrai. Dans les petits utilitaires où ce cosmétique est souhaitable, .NET Framework a jusqu'à présent fait un assez bon travail. Je conviens que c'est esthétique dans le même sens que de pouvoir spécifier une société d'assemblage et un message de copyright. Mais être une chose cosmétique ne me fait pas moins aimer ça. Ce n'est évidemment pas une priorité ici, c'est tout à fait compréhensible.

Peut-être lié: https://github.com/dotnet/core/issues/600

Ce n'est pas principalement cosmétique. Imaginez que je veuille distribuer une application qui a plusieurs composants intégrés à l'intérieur, comme par exemple Idsrv4 ou RavenDb + mes propres trucs. Ils prennent une dépendance sur les bits de base aspnet. Tout cela fonctionne bien tant qu'ils dépendent de la même version d'aspnet core. Dès que l'un d'eux passera à la version suivante, cela ne fonctionnera probablement plus. Si OTOH je pouvais fusionner chaque composant en un seul fichier .dll, le problème disparaîtra.

Une chose à garder à l'esprit est qu'il y a plus de problèmes techniques que simplement ILMerge qui ne fonctionne pas. Le runtime lui-même est fondamentalement divisé en plusieurs fichiers, et il existe également des fichiers auxiliaires tels que l'hôte CLR, le fichier texte des dépendances d'exécution, etc. La seule raison pour laquelle un exécutable à fichier unique a fonctionné dans le passé est que le .NET Framework, une installation globale à l'échelle du système, était utilisé. La comparaison des deux scénarios est un peu injuste, car le .NET Framework n'a pas vraiment d'option «autonome».

Tout cela fonctionne bien tant qu'ils dépendent de la même version d'aspnet core. Dès que l'un d'eux passera à la version suivante, cela ne fonctionnera probablement plus.

Ce n'est pas vraiment vrai. Vous pouvez publier plusieurs applications différentes sur différentes versions d'exécution, puis les regrouper dans la même "uber-app". Vous ne pouvez tout simplement pas mélanger leurs dépendances dans un seul dossier. Même si vous utilisez l'option de publication dépendante de l'infrastructure, vous pouvez toujours mélanger et faire correspondre les versions. Je comprends que c'est moins pratique que d'avoir littéralement un seul fichier, et peut empêcher des choses comme l'incorporation d'un exe en tant que ressource dans le PE. Je ne sais pas si c'est ce à quoi vous faites référence, car vous auriez probablement encore besoin d'extraire le fichier pour l'exécuter, ce que vous pouvez toujours faire avec un répertoire.

Je ne parlais pas de la version d'exécution, je sais que cela ne fonctionnera pas. Ce que je veux dire, c'est ce qui se passe dans mon scénario lorsque chaque composant prend une dépendance sur [email protected]. Le composant a est alors mis à jour vers [email protected]. Normalement c'est bien, mais dans cette hypothèse, les auteurs de LibXYZ ne connaissent pas / ne se soucient pas du versionnage sémantique. Ilmerge a fait disparaître ce problème.

En plus du point pertinent @thefringeninja , je suggérerais qu'une seule unité binaire déployable réduit les frais généraux des opérations. Cela réduit la probabilité que quelque chose ne va pas avec un déploiement, réduit le fardeau d'apprécier cognitivement ce que vous avez expédié et réduit la configuration pour les outils opérationnels, qu'il s'agisse de scripts ou de l'état souhaité.

J'apprécie que l'outillage dotnet soit naissant et vient juste d'atteindre 2.0, mais comparé à des alternatives telles que golang, cette fonctionnalité manque cruellement. Pensez à l'ajouter à la feuille de route?

En tant que développeur de bibliothèques, j'apprécierais que ILMerge soit de retour dans Core. 👍

Dotnet.exe est un seul fichier. NuGet.exe est un seul fichier. Je pense que les cosmétiques sont importants, et un seul fichier exe crie la simplicité comme un dossier avec 100 fichiers ne le fait pas! Ce serait formidable de trouver un moyen d'y parvenir avec dotnetcore

J'ai supposé que c'était possible, et après plusieurs semaines de travail, je suis venu publier un outil de console CLI sur un seul .exe ... ummm semble pour le moment je ne peux pas obtenir un seul * .exe ??
Je pensais que c'était le but des applications de base autonomes?

@PRIMETSS

Je pensais que c'était le but des applications de base autonomes?

L'intérêt des applications autonomes est qu'elles sont autonomes, c'est-à-dire qu'elles ne nécessitent pas l'installation de .Net Core sur la machine cible, car l'application elle-même contient tout ce dont elle a besoin pour s'exécuter.

Pour déployer une telle application, vous devez copier un répertoire entier de fichiers. Avoir un seul fichier faciliterait le déploiement, mais c'est tout, c'est toujours une application autonome même sans cela.

Pour les applications de grande taille et de type service, ce n'est peut-être pas si important, mais il est essentiel que les outils de ligne de commande et les petites applications soient aussi simples que possible et conviviaux pour le déploiement de COPY.

J'écris régulièrement des outils de ligne de commande dans .NET et les avoir comme 1 EXE rend les mises à niveau / déploiements / empaquetage beaucoup plus simples. J'emballe toujours tous les .config et autres fichiers requis dans EXE.

Considérez cet EXE unique comme un mini-conteneur. Presque tous les avantages des déploiements basés sur des conteneurs s'appliquent ici.

C'est juste horrible je me demande pourquoi cela a été approuvé pendant le processus de conception, je veux distribuer votre application à l'un de vos clients, puis bonne chance à lui pour trouver ce qu'il faut ouvrir:

C'est juste moche et un désordre complet

Durée/
MyProgram.exe
MyLib.dll

Cela aurait été une bien meilleure idée

Même Java gère mieux cela:

Oui, je pensais dans le même sens, puisque les applications autonomes doivent contenir les fichiers d'exécution (évidemment!) (Et nous n'avons pas de moyen de les fusionner), alors j'ai également pensé qu'une simple séparation de dossiers être plus soigné, et oui, je pense aussi que les fichiers d'exécution devraient être stockés dans un dossier d'exécution, donc quiconque essaie d'utiliser un outil de ligne de commande écrit dans le noyau, le trouverait au moins un peu plus intuitif que ce qu'il faut exécuter.

@Scellow @PRIMETSS Je dois accepter

Comment est-ce encore un problème? La demande est à travers le toit pour cela.

oui à ce dossier séparé avec l'ajout de compresser cela dans un bac et avoir deux fichiers, l'exe et le bac. Distribution facile.

Un autre +1 pour rouvrir et avoir comme fonctionnalité.

Je m'attendais à ce que le déploiement autonome soit autonome et trouve mon chemin ici. J'aimerais aussi que cela se produise.

Comment peut-on dire que ce n'est qu'un problème cosmétique? (Seulement les développeurs de Framework ...)
Personne n'a pensé à des outils qui ne sont pas installés? (.NET a résolu dll-hell, et .net core le ramène)

Je veux juste que mon outil de ligne de commande soit autonome.

C'est mauvais, vraiment mauvais!

+1

+1 Je viens d'essayer d'exécuter une activité personnalisée dans Azure Batch sur un cluster sans runtime principal .net et il ne peut pas gérer le nombre élevé de fichiers créés par la version «autonome».

Total size of resourceFiles cannot be more than 32768 characters

Ce n'est pas une solution officielle, mais cela pourrait être utile. Je suis l'auteur de warp, un outil qui vous permet de créer des applications binaires uniques autonomes: https://github.com/dgiagio/warp

Je pense que le warp est fondamentalement ce que tout le monde recherche ici! Il s'agit simplement de la possibilité d'avoir un seul fichier exe, quel qu'il soit en arrière-plan, rien de plus. Pensez aux packages NuGet: c'est un seul fichier .nuget et c'est tout; ce n'est pas quelque chose de plus complexe qu'un fichier empaquetant d'autres fichiers.

warp est une solution hacky, ce n'est pas ce que nous voulons

Ce que nous voulons c'est:

dotnet publish --self-contained -c Release -r win10-x64

Et cela produit:

App.exe
runtime/

Ou mieux comme GO / Rust etc.

App.exe

Tout le reste n'est pas voulu

Warp produit un App.exe ... Comment est-il piraté? Évidemment, cela ne fait pas partie du cadre, mais atteint l'objectif "un fichier exe".

C'est ce que je veux dire, cela devrait être le comportement par défaut, ne pas utiliser de solution tierce (je pense)

Warp fonctionne un régal. Merci pour votre travail @dgiagio!

+1

J'aimerais beaucoup voir une sorte d'archive à fichier unique qui regroupe l'exécutable et toutes les dépendances. Il n'est pas nécessaire d'inclure les natifs - je pense qu'il est parfaitement normal d'exiger que dotnet core soit installé sur le système. Quelque chose de très similaire aux fichiers jar de Java. Un fichier Dar?

Quelque chose comme:
dotnet publish - autonome
dotnet run - MyApp.dar autonome

Il semble qu'il y ait une proposition pour cela maintenant: https://github.com/dotnet/designs/pull/52/files?short_path=28dba55

Voici le problème de suivi: https://github.com/dotnet/coreclr/issues/20287

De plus, @shanselman a un article de blog sur la solution Warp:

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

J'ai lu la proposition et j'ai vu ceci:

Ce n'est pas ce que j'avais à l'esprit, cela ressemble à un processus lent, qui consiste simplement à tout zipper ..
Je pensais que tout le code serait fusionné en un seul exécutable / dll? ou peut-être ai-je manqué quelque chose dans la proposition?

@RUSshy Vous

Cependant, il existe des solutions proposées pour réduire l'extraction du disque et le temps de démarrage (ex: charger certains types de fichiers directement à partir du bundle , réutiliser les fichiers extraits ). Les étapes de développement de la solution mono-fichier sont décrites ici .

CC: @jeffschwMSFT

Pourquoi les fichiers doivent-ils être extraits? Nous avions l'habitude de nous en sortir avec .NET avec ILMerge.

@ phillip-haydon, comme décrit ici , ILMerge et les solutions à fichier unique atteignent des objectifs différents.

ILMerge combine l'IL de nombreux assemblys en un seul, mais au cours du processus, perd l'identité d'origine des assemblys fusionnés. Ainsi, des choses comme l'utilisation de la réflexion basée sur les noms d'assemblage d'origine échoueront. Les applications peuvent toujours utiliser ILMerge si elles peuvent tolérer ce changement.

CoreRT est autre chose, la compilation AOT de votre code .NET, cela semble intéressant, mais pas encore prêt (j'aimerais que MS se concentre dessus et alloue plus de ressources ... c'est exactement ce que les gens veulent, et pourquoi ils sont passés à GO )

Quoi qu'il en soit, je n'ai pas de connaissances techniques pour parler des détails, mais le cas d'utilisation est:

Publiez un seul exécutable autonome, et juste ça, rien de compressé, rien d'extrait, pas de surcharge, juste l'exécutable

@ swaroop-sridhar avez-vous un exemple de ce fonctionnement pour dotnet core sur linux? selon https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13, il s'agit d'un projet Windows / mono uniquement.

@thefringeninja ILMerge est un outil Windows, je ne connais aucun projet de portage d'ILMerge sur d'autres plates-formes.
La solution Single-file sera implémentée multiplateforme. Ceci est en cours de développement.

@karelz @mellinoe
Déployer Déployer Déployer!si unique ou moins comme 1 à 3 fichiers, ce sera mieux pour le déploiement (Inlcude Publish, Update)!

CoreRT est AOT
mais les personnes veulent-elles AOT?
le projet (CoreRT) n'est toujours pas prêt à utiliser (il date de 2014). C'est maintenant 2019! ( Environ 5 ans )
Quel précieux 5 ans pour un langage pragram!le CoreRT même pas de plan pour la prochaine version !!!laisser ppl attendre encore 5 ans?

@ swaroop-sridhar C'est malheureux. ILMerge / ILRepack est idéal pour les développeurs de bibliothèques afin d'éviter le problème de dépendance de diamant.

Il est prévu de le prendre en charge dans .NET Core 3.0 - @richlander peut vous mettre à jour sur l'état.
Cela a été mentionné dans les articles de blog .NET Core 3.0 - par exemple ici: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ dans "Side-by- côté et déploiement local de l'application ".
Lisez également: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

.net ne devrait pas avoir besoin de tous ces hacks pour produire un petit exécutable autonome unique .. cela devrait être le comportement par défaut, vous êtes mangé vivant par GO, Rust arrive aussi, concentrez-vous sur CoreRT ou ILMerge, les applications de base .net le sont déjà aussi long pour commencer à cause de tous les fichiers à charger, n'ajoutez pas plus entendu à cela avec zip / unzip comme mentionné dans la proposition, ce n'est pas la voie à suivre

.net ne devrait pas avoir besoin de tous ces hacks pour produire un petit exécutable autonome unique .. cela devrait être le comportement par défaut, vous êtes mangé vivant par GO, Rust arrive aussi, concentrez-vous sur CoreRT ou ILMerge, les applications de base .net le sont déjà aussi long pour commencer à cause de tous les fichiers à charger, n'ajoutez pas plus entendu à cela avec zip / unzip comme mentionné dans la proposition, ce n'est pas la voie à suivre

Comme vous le souhaitez, .net ne devrait pas avoir besoin de vivant, car ppl a java.
go ou rust ou dlang ne devraient pas prendre en charge la cible de compilation vers le programme exécutable unique, car ils ont le Fuck Zip / Unzip!

@RUSshy

.net ne devrait pas avoir besoin de tous ces hacks pour produire un petit exécutable autonome

D'accord. En même temps, .NET fournit certaines fonctionnalités par rapport à d'autres langages qui sont difficiles à concilier avec les exigences d'un éditeur de liens statique (par exemple, la génération de code à la volée, la réflexion, la liaison de données, etc.). Nous avons expérimenté l'exclusion de ces fonctionnalités dans des scénarios où la liaison fichier / statique unique est importante. Nous avons appris des commentaires des clients que le résultat ne ressemble plus à .NET, en partie parce que le nombre de bibliothèques que vous pouvez consommer à partir de l'écosystème diminue considérablement.

Donc, faire un éditeur de liens correctement qui ne compromet pas la fidélité des fonctionnalités que nous avons tous pris une dépendance et aimons dans .NET, est un problème difficile. Pour résoudre ce problème, nous expérimentons différentes approches. Vous appelez cela des hacks, j'appelle cela ouvert d'esprit et prêt à sortir des sentiers battus. Mais transformer aveuglément .NET en Go / Rust / C ++ n'est pas la bonne réponse.

Nous avons expérimenté l'exclusion de ces fonctionnalités dans des scénarios où la liaison fichier / statique unique est importante. Nous avons appris des commentaires des clients que le résultat ne ressemble plus à .NET, en partie parce que le nombre de bibliothèques que vous pouvez consommer à partir de l'écosystème diminue considérablement.

L'équipe a-t-elle pensé à créer une version distincte de .net axée sur le développement natif et les environnements contraints, comme l'a fait jetbrains avec kotlin JVM / kotlin NATIVE?

Comme vous l'avez dit, essayer d'adapter .net à tous les cas d'utilisation n'est pas l'option la plus intelligente, donc une saveur spécifique pourrait être la bonne réponse à ce problème

Et tbh, afaik, ce problème n'existait pas vraiment avant .net core puisque chaque installation de Windows avait déjà un framework .net, vous n'aviez donc qu'à distribuer vos quelques KBs exe, et ce qui m'ennuie, c'est que personne ne semble avoir pensé à ce genre de problème lors de la conception de .net core qui était essentiellement une réécriture du framework .net .. c'est pourquoi je dis que ces options mentionnées sont des hacks simples, elles sont là pour corriger les erreurs de conception

Après avoir lu https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md, il semble y avoir plus d'étapes pour la proposition, et elle ne se termine pas par zip / unzip, donc ce n'est pas un combat perdu, j'espère que l'équipe pourra venir avec quelque chose de plus léger, qui est mentionné dans ce document, bien!

Des choses comme celles-ci expliquent pourquoi Windows reste un système d'exploitation jouet.

@kjkrum Des choses comme quoi?

@cryru, c'est ce que les gens disent quand ils ne savent pas ce qu'ils font.

@Cryru Des choses comme ne pas être en mesure de créer un exécutable autonome et le rejet inconscient de la nécessité très réelle de le faire. Pratiquement tous les autres systèmes de construction existants ne construiront pas seulement un exécutable lié statiquement, il supprimera les parties inutilisées des dépendances. La suppression des dépendances est une fonctionnalité standard depuis au moins une décennie; liaison statique depuis l'invention des compleurs.

@Cryru Des choses comme ne pas être en mesure de créer un exécutable autonome et le rejet inconscient de la nécessité très réelle de le faire. Pratiquement tous les autres systèmes de construction existants ne construiront pas seulement un exécutable lié statiquement, il supprimera les parties inutilisées des dépendances. La suppression des dépendances est une fonctionnalité standard depuis au moins une décennie; liaison statique depuis l'invention des compleurs.

D'accord, c'est en fait lié à la position des programmes C # dans le système d'exploitation.
Les programmes C # ne peuvent toujours pas devenir des citoyens de première classe.Seulement pour être la deuxième classe.

Ceci est résolu.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Détails:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Ceci est résolu.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Détails:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Dans quelle version de dotnet-core cette fonctionnalité a-t-elle été ajoutée? J'utilise 3.0.100-preview5-011568 et j'ai cette erreur:
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE: En fait, cela fonctionne, il semble seulement qu'il y ait une erreur de syntaxe dans le https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md qui indique la publication avec dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true et est en fait sans ajouter --self-contained .

Merci @mihaimyh Je corrigerai la faute de frappe dans le document de conception.

Je suis toujours contre l'utilisation de la solution zip / unzip pour la fonction autonome d'exe unique .
car cela causera le prochain problème.
Comment réduire la taille du fichier unique exe!

En fait, dès le départ devrait utiliser IL-Merge de manière similaire.

Il ne devrait pas y avoir de débat, c'est une perte de temps, personne n'a demandé de compresser / décompresser le tout, et pourtant ils sont venus avec ce design et ont perdu leur temps et le nôtre

Les gens demandent un exécutable unique et AOT, arrêtez de perdre notre temps Microsoft

Je veux explicitement un fichier unique sans AOT. Je préfère la possibilité de JIT afin de pouvoir utiliser la réflexion, les génériques et le code généré par l'exécution.

Je suppose que MS ne veut pas entendre, d'accord

Je suis toujours contre l'utilisation de la solution zip / unzip pour la fonction autonome d'exe unique .
car cela causera le prochain problème.
Comment réduire la taille du fichier unique exe!

Je ne suis pas sûr de comprendre, comme si son zip était déjà compressé. Ou voulez-vous dire une réduction des dépendances redondantes et donc une taille réduite avant la compression?

Ne pas comprendre la négativité. Je ne l'ai pas encore utilisé à part un test rapide. Mais il semble que l'exécutable unique fonctionne bien pour la situation de déploiement d'une application sur le client ou en tant qu'outil CLI. C'est là que je pense que cette fonctionnalité est utile. En dehors de cela, dans Dev ou dans un autre environnement, je ne vois pas de cas d'utilisation, donc ce qu'ils ont fait fonctionne très bien comme solution pour le moment.

@RUSshy

Je suppose que MS ne veut pas entendre, d'accord

Au contraire, ils demandent et collectent un large éventail de cas d'utilisation que vous pouvez voir dans les threads associés. Votre opinion est importante, mais les opinions des autres membres de la communauté sont tout aussi importantes et vous ne devriez pas vous moquer de Microsoft pour les avoir écoutées.

Sur la base de votre déclaration, je pense que vous m'avez peut-être confondu avec Microsoft. Je suis juste un membre de la communauté comme vous qui ne parle en aucun cas au nom de Microsoft.

Je suis toujours contre l'utilisation de la solution zip / unzip pour la fonction autonome d'exe unique .
car cela causera le prochain problème.
Comment réduire la taille du fichier unique exe!

Je ne suis pas sûr de comprendre, comme si son zip était déjà compressé. Ou voulez-vous dire une réduction des dépendances redondantes et donc une taille réduite avant la compression?

si vous utilisez WebApi ou MVC ou ConsoleApp, écrivez un HelloWorld! tu sais bien ce que je veux dire.
le fichier compressé est trop volumineux, il apporte trop de code mais ne sera jamais exécuté.
si IL-Merge manières réduira la branche de code inutilisée.

Oui bien sûr j'ai fait une console HelloWorld et oui bien sûr son 68K

Le non autonome était de 67K
Mais son C # n'est pas l'assembly. Si je voulais un HelloWorld <1K, pourquoi utiliser c #?
Les applications plus volumineuses utilisent davantage le framework, donc à un moment donné, son code est plus personnalisé que le framework.
Sommes-nous vraiment inquiets pour quelques 100K? Si tel est le cas, n'utilisez pas de framework et passez le temps à tout écrire à partir de zéro ??
Qu'est-ce que j'oublie ici?

Je suis toujours contre l'utilisation de la solution zip / unzip pour la fonction autonome d'exe unique .
car cela causera le prochain problème.
Comment réduire la taille du fichier unique exe!
si vous utilisez WebApi ou MVC ou ConsoleApp, écrivez un HelloWorld! tu sais bien ce que je veux dire.
le fichier compressé est trop volumineux, il apporte trop de code mais ne sera jamais exécuté.
si IL-Merge manières réduira la branche de code inutilisée.

@sgf, il y a deux problèmes quelque peu distincts ici:

• Comment réduire le code d'une application?
• Comment emballer l'application dans un seul fichier?

Pour la réduction du code, il existe plusieurs techniques supplémentaires

• Fusion d'IL: ce n'est pas pour toutes les applications, car il perd l'identité d'assembly dans le processus. Ce n'est pas un objectif pour le travail actuel sur un seul exe.
• Couper l' IL inutilisé: L' PublishTrimmed ), et d'autres optimisations dans ILLinker sont en cours de développement.
• Zip / Unzip: dotnet publish ne zip actuellement pas le fichier unique publié, mais cela peut être fait.

Comment emballer l'application dans un seul fichier?
dotnet publish prend en charge la publication dans un seul fichier - le fichier publié sera aussi gros que l'application le serait autrement.

Concernant la génération de code natif:

• Actuellement, la prise en charge de la génération de code natif se fait via un compilateur prêt à l'emploi (propriété PublishReadyToRun ).
• La publication via la compilation AOT est excellente ( CoreRT ), mais elle n'est pas encore disponible. Avec la compilation AOT aussi, la taille de l'exécutable dépend des options de compilation: ex: incluons-nous le jit pour exécuter le code généré, etc.?

Oui bien sûr j'ai fait une console HelloWorld et oui bien sûr son 68K

Le non autonome était de 67K
Mais son C # n'est pas l'assembly. Si je voulais un HelloWorld <1K, pourquoi utiliser c #?
Les applications plus volumineuses utilisent davantage le framework, donc à un moment donné, son code est plus personnalisé que le framework.
Sommes-nous vraiment inquiets pour quelques 100K? Si tel est le cas, n'utilisez pas de framework et passez le temps à tout écrire à partir de zéro ??
Qu'est-ce que j'oublie ici?

désolé comme le montre votre img, avec auto contianed.Thats 68626KB, c'est environ 68mb = 68KK, pas seulement 68K !!!
nous n'aurons pas besoin de <1kb (avec auto contianed c'est impossible), <3000KB est ok, acceptez.
Mais 68 Mo, c'est plus 30X +
Vous n'écrirez pas toujours un programme HelloWorld !!!

Excuses, erreur tard dans la nuit avec les K
Merci pour l'explication / info supplémentaire swaroop-sridhar, quelques nouveaux commutateurs là-bas, je n'étais pas au courant.
Je viens d'essayer avec 3.preview 6 avec les commutateurs suivants

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
et maintenant jusqu'à 29 000K

Bien sûr, toutes les applications ne seront pas Hello World, mais pour une application C # Core SelfContained, qui contient également le runtime ... Personnellement, je ne suis pas inquiet. Bien sûr, je comprends que si vous écrivez un petit outil de console, ce serait bien de l'avoir 3K. Mais pourquoi utiliser C # pour cela en premier lieu?
Discussion intéressante entre les gars!

30mb LOL, appelez-moi quand ce sera quelque chose comme 1-3mb, le temps d'exécution est plein de ballonnements, vérifiez GO, les gens migrent par vague

https://www.jetbrains.com/lp/devecosystem-2019/

Même Kotlin commence à gagner des parts, et avec Kotlin Native, cela fait honte à C #

Et Swift arrive sur Windows https://forums.swift.org/t/swift-win32-programming/20686

Alors voici quelques suggestions:

• Ajouter une option pour supprimer la réflexion
• Ajouter une option pour supprimer les éléments JIT
• Mieux vaut optimiser le code C # pour ne pas compter sur JIT

30mb LOL, appelez-moi quand ce sera quelque chose comme 1-3mb, le temps d'exécution est plein de ballonnements, vérifiez GO, les gens migrent par vague

https://www.jetbrains.com/lp/devecosystem-2019/

Même Kotlin commence à gagner des parts, et avec Kotlin Native, cela fait honte à C #

Et Swift arrive sur Windows https://forums.swift.org/t/swift-win32-programming/20686

Alors voici quelques suggestions:

• Ajouter une option pour supprimer la réflexion
• Ajouter une option pour supprimer les éléments JIT
• Mieux vaut optimiser le code C # pour ne pas compter sur JIT

Je pense que ce n'est pas juste. .NET n'a pas été conçu pour créer les plus petites applications de console à fichier unique. Nous l'utilisons pour les sites Web et les API Asp.Net. Par conséquent, le framework lui-même apporte une tonne de fonctionnalités en plus de tonnes de packages nuget que vous pouvez inclure. Je ne peux pas imaginer qu'il y ait un problème si une application Web fait 50 ou plusieurs centaines de mégaoctets. La principale préoccupation est la vitesse, l'utilisation de la mémoire et la maintenabilité à long terme. Qui se soucie de la taille sur le serveur.

Si votre seule intention est de créer une petite application console de taille unique en mb, pourquoi ne pas utiliser le bon outil pour le travail. Au lieu de se plaindre qu'une application avec un framework complet emballé dans un seul fichier fait plusieurs dizaines de mégaoctets, même pour un "bon monde", pourquoi ne pas utiliser Rust par exemple?

Microsoft fait un excellent travail avec .NET depuis ses débuts et encore plus ces dernières années, alors merci pour cela.

Que répondre à un tel non-sens, des mensonges et un manque de sens de l'efficacité?

Vous ne réalisez pas à quel point la direction principale de .net était incorrecte, et ce n'est que récemment qu'ils ont commencé à le réaliser en travaillant sur Distribution / IL Merge / AOT

Et maintenant, pour passer au wagon d'assemblage Web, ils ne peuvent pas car le runtime .net est tellement énorme qu'ils sont incapables de déployer des fichiers de taille décente

Et vous êtes toujours coincé avec "Qui se soucie de la taille sur le serveur.", Cette façon de penser est ce qui a fait du noyau .net "supposé être moderne" en une pile technologique déjà obsolète et non pertinente

Microsoft ne fait pas du bon travail avec .net, ils ont échoué parce qu'ils voulaient plaire aux personnes âgées pour la compatibilité du framework .net, c'était l'une de leurs erreurs

Désolé si j'ai l'air impoli mais parfois vous devez être pour faire des changements

Désolé si j'ai l'air impoli mais

Vous semblez impoli, point final. Cela, ainsi que vos congédiements et vos sauts aux conclusions, n'ont pas pour effet d'être convaincants.

Excuses, erreur tard dans la nuit avec les K
Merci pour l'explication / info supplémentaire swaroop-sridhar, quelques nouveaux commutateurs là-bas, je n'étais pas au courant.
Je viens d'essayer avec 3.preview 6 avec les commutateurs suivants

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
et maintenant jusqu'à 29 000K

Bien sûr, toutes les applications ne seront pas Hello World, mais pour une application C # Core SelfContained, qui contient également le runtime ... Personnellement, je ne suis pas inquiet. Bien sûr, je comprends que si vous écrivez un petit outil de console, ce serait bien de l'avoir 3K. Mais pourquoi utiliser C # pour cela en premier lieu?
Discussion intéressante entre les gars!

en tant que langue moderne, ne devrait-elle pas avoir un peu d'ambition pour unifier le monde?
Voulez-vous que tous les développeurs écrivent c # à la maison pour C ++? ou les pousser à Go, Kotlin, Swift?
Part de marché et érode davantage le c #?

.Net car ne met pas en œuvre multiplateforme a raté les 15 premières années de la grande opportunité de développement.
Mais maintenant .net est de retour sur la bonne voie.

Ouais, comme je l'ai commenté avant, je ne sais pas pourquoi la négativité.
.Net Core n'a été rien d'autre que fantastique si vous venez de Full Framework. Et la vision de la fusion .Net Standard + Core, je pense, est sensée et progressive.

Comparer .NET à GO ou à tout autre langage / framework est inutile.
Quoi qu'il en soit, je suis OUT sur ce sujet, car je pense que la solution sur laquelle ils travaillent et améliorent pour Single .exe a assez bien résolu ma «demande» de plusieurs années en arrière ... Assez bien pour moi, et convient à mes besoins immédiats.

Alors merci Guys & Gals!

EN DEHORS

Je voudrais rappeler à tout le monde sur ce fil à propos du code de conduite .

Il est normal d'être en désaccord ou d'avoir une opinion différente, mais s'il vous plaît, soyons courtois et exprimons cela sous forme de discussion technique. Pas besoin d'utiliser des mots forts.
En outre, cibler les idées, les implémentations avec vos opinions est une bonne chose. CEPENDANT, il n'est PAS ACCEPTABLE d'attaquer les PERSONNES derrière eux. Soyons tous respectueux les uns envers les autres, écoutons des opinions différentes et évitons les déclarations fortes et les commentaires offensants.

Aussi, j'aimerais demander à tout le monde d'être ouvert à d'autres points de vue et opinions. Avant de porter un jugement, il est généralement bon d'entendre l'autre côté - il y a souvent une histoire derrière pourquoi les choses sont comme elles sont. Pousser des idées et des solutions quand on sait pourquoi elles sont telles qu'elles sont est généralement plus productif.

Je vous remercie!

Je suis toujours contre l'utilisation de la solution zip / unzip pour la fonction autonome d'exe unique .
car cela causera le prochain problème.
Comment réduire la taille du fichier unique exe!
si vous utilisez WebApi ou MVC ou ConsoleApp, écrivez un HelloWorld! tu sais bien ce que je veux dire.
le fichier compressé est trop volumineux, il apporte trop de code mais ne sera jamais exécuté.
si IL-Merge manières réduira la branche de code inutilisée.

@sgf, il y a deux problèmes quelque peu distincts ici:

• Comment réduire le code d'une application?
• Comment emballer l'application dans un seul fichier?

Pour la réduction du code, il existe plusieurs techniques supplémentaires

• Fusion d'IL: ce n'est pas pour toutes les applications, car il perd l'identité d'assembly dans le processus. Ce n'est pas un objectif pour le travail actuel sur un seul exe.
• Couper l' IL inutilisé: L' PublishTrimmed ), et d'autres optimisations dans ILLinker sont en cours de développement.
• Zip / Unzip: dotnet publish ne zip actuellement pas le fichier unique publié, mais cela peut être fait.

Comment emballer l'application dans un seul fichier?
dotnet publish prend en charge la publication dans un seul fichier - le fichier publié sera aussi gros que l'application le serait autrement.

Concernant la génération de code natif:

• Actuellement, la prise en charge de la génération de code natif se fait via un compilateur prêt à l'emploi (propriété PublishReadyToRun ).
• La publication via la compilation AOT est excellente ( CoreRT ), mais elle n'est pas encore disponible. Avec la compilation AOT aussi, la taille de l'exécutable dépend des options de compilation: ex: incluons-nous le jit pour exécuter le code généré, etc.?

Au besoin, fusionnez les DLL natives en un seul nom comme: XXX.exe (non géré).
Utilisation de l'analyse statique pour l'analyse lors de la compilation de la liaison au niveau de la fonction nativeDLLs (UnManaged).

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

si vous faites du bon travail, le résultat sera peut-être 2-3mb. quand je suis directement emballé avec 7zip, cela prend environ 4,85 Mo. Maintenant, nous obtenons XXX.exe

développer le lien de niveau de fonction similaire avec IL-merge.
Pour une DLL gérée, la même vieille astuce.
Enfin, intégrez la DLL gérée en tant que sections PE.exe (marquez comme section .net).

Pour refléter, DLL d'analyse de type réflexion. Conservez les métadonnées et le type de réflexion (y compris la fonction) et tout ce qui dépend de l 'arbre.

Je m'excuse, je ne veux plus prendre plus de temps pour participer à la discussion à ce sujet, les opinions ne peuvent pas être unifiées.
Au début, je m'attendais au résultat. Mais maintenant, je devrais probablement envisager d'autres langages de programmation pour répondre à mes besoins (peut-être Dlang peut-être Go peut-être Kotlin peut-être Nim ou peut-être Rust est le meilleur).

merci pour tout parler avec moi. désolé pour mon harcèlement. en dehors

@sgf Je pense que vous avez

1. Mono prend déjà en charge la compilation AOT avec Linking pour réduire la taille du fichier. C'est l'une des raisons pour lesquelles mono a été choisi pour l'implémentation d'exécution du navigateur .net. https://www.mono-project.com/docs/advanced/aot/ et je suppose que c'est pourquoi les projets Blazor peuvent avoir un Linker.

2. Microsoft a déclaré vouloir regrouper ses environnements d'exécution .NET en un seul "tout puissant". Plutôt que d'avoir mono pour certaines choses et .NET Core pour d'autres, ils veulent un runtime unique capable de répondre à tous les scénarios. Ce defacto signifie qu'il devra prendre en charge AOT et Linking / Code stripping, etc. Par conséquent, je prévois qu'au cours des prochaines années, soit le runtime .NET Core obtiendra ces fonctionnalités, soit les fonctionnalités Mono et .NET Core seront consolidées dans un nouveau Durée.

Si quelqu'un sait mieux, merci de m'en informer.

+ 2 ¢

Je pense que le problème est qu'il semble que les décisions sont prises sans beaucoup d'informations. Ces jours-ci, partout où je regarde, les gens en parlent; la grande majorité des personnes qui déploient des programmes ont cette au - dessus de leur liste de souhaits, et beaucoup se détournent de C # à d' autres langues avec une meilleure AOT / déployabilité. Je pense que c'est un fait assez établi qui devient très évident si vous êtes actif dans la communauté. Pourtant, cela ne semble pas affecter le moins du monde les décisions.

Le fait est que personne ne sait exactement dans quelle mesure cela est important. Pour moi personnellement, c'est extrêmement important, donc bien sûr je suis très partial, mais l'impression que j'ai, c'est que dans l'ensemble, c'est d'une importance primordiale et il semble que la SP ne lui accorde tout simplement pas l'attention qu'elle mérite, laissant à beaucoup d'entre nous l'impression ils prennent des décisions en uniforme, ce qui ne nous rend pas confiants quant à l'avenir de la technologie dans son ensemble.

Je suis d'accord avec @RUSshy. CoreRT est un projet incroyable et va certainement dans la bonne direction, mais dans l'ensemble, il semble que tous les efforts soient concentrés sur les technologies serveur / Web. Des choses comme les runtimes, les jits et les grands binaires parlent d'eux-mêmes à cet égard. Personne qui déploie un logiciel ne veut ces choses.

Cela étant dit, personnellement, j'utilise toujours la technologie même si je ne me retiens pas vraiment de son avenir dans certains domaines.

J'aimerais voir plus de participation de la communauté dans la direction prise, même s'il s'avère que c'est le contraire de ce que j'attends personnellement. Mais jusqu'à présent, il semble que des décisions soient prises sans en tenir compte. Il semble que le serveur / Web soit ce qui rapporte de l'argent et que les personnes qui déploient des programmes sont une minorité négligeable (au moins en termes de bénéfices), mais si c'est le cas, je voudrais au moins savoir sur quoi ils fondent leurs décisions (sur lesquelles est très probable), car de l'extérieur, on dirait qu'ils lancent une pièce.

@ Alan-FGR

Mais jusqu'à présent, il semble que des décisions soient prises sans en tenir compte.

Avez-vous des exemples spécifiques de telles décisions à partager, car je serais curieux d'en savoir plus.

Je pense que MS sont très conscients des lacunes du moteur d'exécution dotnet actuel et c'est pourquoi ils chercheront à l'avenir la parité des fonctionnalités avec le moteur d'exécution mono.

Consultez simplement les notes de publication de .net core 3.0.0 preview 6:

Aujourd'hui, nous annonçons .NET Core 3.0 Preview 6. Il comprend des mises à jour pour la compilation d'assemblys pour un démarrage amélioré, l'optimisation des applications pour la taille avec des améliorations de l'éditeur de liens et d'EventPipe. Nous avons également publié de nouvelles images Docker pour Alpine sur ARM64.

Il me semble qu'ils sont très conscients que la taille de l'application est importante pour certains scénarios - en particulier maintenant avec Blazor dans le mix.

@ Alan-FGR D'accord, l'accent sur le Web est plutôt étrange étant donné que IIS détient environ 8% de part de marché et diminue. ASP.NET n'est pas pertinent et aucune amélioration de C # ou de ses bibliothèques standard ne changera jamais cela. C # est soutenu par les applications console, les services Windows, les applications mobiles et les jeux PC. Il doit son existence continue à Unity et Xamarin. Ce qui est dommage, car C # est un langage vraiment agréable à développer. C'est un éloge de la part d'un développeur Java de longue date qui pense toujours que Microsoft a laissé sa marque avec Windows XP.

Au besoin, fusionnez les DLL natives en un seul nom comme: XXX.exe (non géré).
Utilisation de l'analyse statique pour l'analyse lors de la compilation de la liaison au niveau de la fonction nativeDLLs (UnManaged).

Je ne sais pas ce que vous entendez par fusion dynamique, mais il existe un plan pour relier statiquement les composants natifs à l'hôte. Veuillez consulter cette section .

développer le lien de niveau de fonction similaire avec IL-merge.
Pour refléter, DLL d'analyse de type réflexion. Conservez les métadonnées et le type de réflexion (y compris la fonction) et tout ce qui dépend de l 'arbre.

Nous avons discuté de la possibilité de fusionner des assemblys en un seul et d'avoir des tables de métadonnées latérales pour prendre en charge les fonctionnalités dynamiques. Cela permet des économies de taille considérables. Mais le coût de sa mise en œuvre est assez élevé - en raison du nouveau support des méta-données et des changements nécessaires dans les débogueurs / profileurs, etc. pour le gérer.

Il existe quelques autres options pour réduire la taille binaire - par exemple, lorsque nous sommes en mesure d'exécuter directement un seul fichier (sans avoir à extraire des fichiers), nous pouvons supprimer la signature / les certificats sur chaque DLL en faveur de signer l'application dans son ensemble. Cela peut parfois économiser quelques Mo.

Mais jusqu'à présent, il semble que des décisions soient prises sans en tenir compte.

Avez-vous des exemples spécifiques de telles décisions à partager, car je serais curieux d'en savoir plus.

Je pense que MS sont très conscients des lacunes du moteur d'exécution dotnet actuel et c'est pourquoi ils chercheront à l'avenir la parité des fonctionnalités avec le moteur d'exécution mono.

@dazinator Je pense que le fait même que MS pense que Mono est une solution décente pour tout montre qu'ils ne connaissent vraiment pas leurs produits. J'ai utilisé Mono, et bien qu'il s'agisse d'un élément technologique important et qu'il ait contribué à populariser énormément .NET, il manque définitivement de qualité ... Xamarin a fait un excellent travail de marketing pour promouvoir sa technologie, mais il était basé sur des promesses excessives et sous- livraison, et il semble que quiconque prend ces décisions chez MS vient de voir une partie de leur matériel promotionnel et n'a jamais vraiment utilisé la technologie. CoreRT, en revanche, est une technologie qui, jusqu'à présent, m'a largement dépassé. C'est à un autre niveau de qualité à mon avis, et pourtant il est négligé par MS au profit d'une technologie que je soupçonne d'être tenue avec du ruban adhésif.

D'accord, l'accent sur le Web est plutôt étrange étant donné que IIS détient environ 8% de part de marché et diminue. ASP.NET n'est pas pertinent et aucune amélioration de C # ou de ses bibliothèques standard ne changera jamais cela. C # est soutenu par les applications console, les services Windows, les applications mobiles et les jeux PC.

@kjkrum c'est le point. Cependant, peut-être pour eux 8% de part de marché sur le Web est encore beaucoup plus important que les applications Windows et mobiles. Les bonnes technologies Web aident au moins les ventes de serveurs Windows, donc leur intérêt pour cela est assez évident, mais se concentrer autant sur cela est aussi une stratégie très superficielle et je refuse de croire que c'est ce qui motive leurs décisions. MS semblait aller dans la bonne direction avec la fondation dotnet et tant de projets prometteurs en cours, mais il semble qu'ils laissent passer l'occasion de faire passer une technologie dominante.

Je sais que c'est anecdotique, donc probablement dénué de sens, mais toutes les personnes que je connais qui utilisaient C # pour leurs projets (principalement des développeurs de jeux) sont passées à autre chose en raison de limitations totalement résolubles. Ils sont passés à Rust, D, Go et C ++. J'utilise moi-même régulièrement C ++ et j'apprends Rust, mais j'utilise toujours C # pour certains projets personnels car c'est tellement mieux, même si déployer un produit de qualité est une douleur à l'arrière.

Il doit son existence continue à Unity et Xamarin.

Oui, qu'est-ce qu'une bénédiction et une malédiction à cause des nombreux problèmes techniques. Unity, par exemple, a une très mauvaise réputation mais heureusement cela n'a pas semblé affecter .NET / C #.
XNA cependant, bien que loin d'être parfait, jouit toujours d'une excellente réputation auprès des utilisateurs et des développeurs.

Heureux de voir cette terre avec .NET Core 3.0 aujourd'hui. Merci à tous! 👍

Je ne suis pas sûr que ce soit ce que les gens veulent, si nous nous retrouvons avec une simple calculatrice de 141 Mo exe, alors la fonctionnalité est un échec (et je pense que le coût réel est de 141 Mo * 2, car il va extraire des choses quelque part correctement)

Oui, c'est vraiment ce que je veux. C'est encore plus petit qu'un déploiement autonome régulier.

Une taille d'assemblage plus agressive et une secousse d'arbre seraient les bienvenues, mais c'est un début très utile. L'amélioration progressive est le moyen le plus intelligent de créer de la valeur.

Oh c'est ce que tu veux? mon mauvais, je ne savais pas que l'application gonflée était populaire

Une calculatrice n'a pas besoin de JIT, pas même de Reflection, mais puisque c'est ce que vous voulez, je suppose que j'ai tort depuis le début, je devrais arrêter la programmation

@RUSshy Ce n'est pas plus gonflé que tout autre déploiement autonome, non?

La suppression du JIT et de la réflexion est indépendante du fait que tout soit emballé dans un seul exe. Ie vous pouvez supprimer JIT et la réflexion sans single-exe, et vous pouvez avoir single-exe sans supprimer JIT et la réflexion. Ce sont des travaux distincts.

Je ne suis pas sûr que ce soit ce que les gens veulent, si nous nous retrouvons avec une simple calculatrice de 141 Mo exe, alors la fonctionnalité est un échec (et je pense que le coût réel est de 141 Mo * 2, car il va extraire des choses quelque part correctement)

il extrait les fichiers dans C: Users [YourUserName] AppDataLocalTemp.net

Existe-t-il un moyen de remplacer l'endroit où un seul exe sera décompressé?
J'ai rencontré un problème quand il essaie d'extraire dans / var / .... où l'utilisateur n'a aucune autorisation d'écrire.

@eiva de quel système d'exploitation s'agissait-il? Était-ce AWS lambda?
https://github.com/dotnet/core-setup/issues/7940 pistes corrigeant ce problème.

En attendant, vous pouvez définir la variable d'environnement DOTNET_BUNDLE_EXTRACT_BASE_DIR pour contrôler où les fichiers groupés sont extraits.

@ swaroop-sridhar Merci pour la réponse!
C'est centos.7 qui lance l'application à partir du compte de service "restreint".

@ jnm2 J'apprécie que tu aimes C #, moi aussi. Mais soyons honnêtes, c'est insensé qu'une calculatrice pèse 128 mégaoctets.

@TechnikEmpire Je pense qu'il est nécessaire de souligner que "j'aime C #" est une réduction assez intensive de ce que j'ai dit ci-dessus: D

Personnellement, je ne me sentirai pas entièrement satisfait tant que je n'aurai pas la possibilité de faire trembler l'arborescence de mon propre code et de mes propres bibliothèques, de bibliothèques tierces référencées et de .NET lui-même. Mais cela ne rend pas la fonctionnalité d'exe unique moins précieuse pour moi aujourd'hui. C'est un pas dans une dimension. Le tremblement des arbres est une dimension indépendante qui, je l'espère, suscite beaucoup d'attention.