Building Offline, need more references

[LxLeChat]

Salut, j'ai regardé rapido sur une VM au boulot, mais ce n'est pas facile de construire le projet sans internet... Il y a qq références de package qui ne sont pas explicité dans le fichier projet.

Les dll existantes compilées ne semblent pas fonctionner avec PS v5.1, il manque donc pour ce projet une livraison complète prête à utiliser. Ce qui est préférable si qq veut tester sans avoir à plonger dans le code ;-)

Je regarderais ce WE sur mon poste. Et si le projet cible la v5.1 ne serait-il pas préférable d'utiliser le paquet dédié (dotNet 4.5 je crois) et pas celui nommé NetStandard ?

Originally posted by @LaurentDardenne in https://github.com/LxLeChat/FlowChartCore/issues/101#issuecomment-815955681

[LxLeChat]

c'est ce genre d'erreur que tu as ? (si tu te rappelles ^^ @LaurentDardenne )

La j'ai tenté un build sur windows sandbox (déconnecté du réseau)

Edit: Pour ref: lister les packages utilisés et nécessaire au restore et donc au build:

dotnet list package
dotnet list <path to csproj> package

à partir de la il semble qu'il faille une config nuget local: https://stackoverflow.com/questions/43400069/add-a-package-with-a-local-package-file-in-dotnet

[LaurentDardenne]

Non, mais c'est lié je pense. >>tester sans avoir à plonger dans le code ;-) Ce qui importe est d'avoir une livraison complète pour les deux cibles, le build est nécessaire uniquement si on veut modifier le code C# à partir d'une machine qui n'a pas de connexion internet.

Qq pistes avec les mots clés "c# compile project without internet", mais tu peux passer à autre chose je regarderais la semaine prochaine. J'ai eu d'autres soucis de ce type, notamment obtenir une licence pour VS community.

[LxLeChat]

bon ... ayé ! pour que ça fonctionne j'ai du telecharger ... un certain nombre de package nuget ... voila la liste complete:

dotnetgraph.2.6.0.nupkg
microsoft.applicationinsights.2.13.1.nupkg
microsoft.management.infrastructure.2.0.0.nupkg
microsoft.management.infrastructure.runtime.unix.2.0.0.nupkg
microsoft.management.infrastructure.runtime.win.2.0.0.nupkg
microsoft.netcore.platforms.3.1.0.nupkg
microsoft.powershell.coreclr.eventing.7.0.0.nupkg
microsoft.powershell.native.7.0.0 (1).nupkg
microsoft.powershell.native.7.0.0.nupkg
microsoft.win32.registry.4.7.0.nupkg
microsoft.win32.registry.accesscontrol.4.7.0.nupkg
microsoft.win32.systemevents.4.7.0.nupkg
netstandard.library.2.0.3.nupkg
newtonsoft.json.12.0.3.nupkg
nuget.config
powershellstandard.library.5.1.0.nupkg
system.codedom.4.7.0.nupkg
system.configuration.configurationmanager.4.7.0.nupkg
system.diagnostics.diagnosticsource.4.7.0.nupkg
system.diagnostics.eventlog.4.7.0.nupkg
system.directoryservices.4.7.0.nupkg
system.drawing.common.4.7.0.nupkg
system.io.filesystem.accesscontrol.4.7.0.nupkg
system.management.4.7.0.nupkg
system.management.automation.7.0.0.nupkg
system.runtime.compilerservices.unsafe.4.7.1.nupkg
system.security.accesscontrol.4.7.0.nupkg
system.security.cryptography.cng.4.7.0.nupkg
system.security.cryptography.pkcs.4.7.0.nupkg
system.security.cryptography.protecteddata.4.7.0.nupkg
system.security.permissions.4.7.0.nupkg
system.security.principal.windows.4.7.0.nupkg
system.text.encoding.codepages.4.7.0.nupkg
system.windows.extensions.4.7.0.nupkg

Après il suffit d'avoir un fichier nuget.config avec la conf suivante:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="<Path to Project\Src\Packages"/>
  </packageSources>
</configuration>

et à partir de la on peut faire: dotnet restore --configfile <path to custo nuget config file> dotnet build --configfile <path to custo nuget config file>

ça sort du warning mais je pense pas que ça soit grave .. ! [edit] ces warnings sont liés au fait que j'ai des mis des packages plus 'récents' ... ! rien de bien méchant donc ! Pour virer les warning il suffit d'ajouter /nowarn:NU1603 dotnet restore --configfile <path to custo nuget config file> /nowarn:NU1603 ``dotnet build --configfile /nowarn:NU1603```

si tu ne veux pas à avoir a dll la liste de fichier, je peux éventuellement la déposer sur le repo en zip [Edit] J'ai uploader sur la branche frameworks le zip contenant tous les packages nuget, dans le répertoire src\packages

mais bon je trouve ça étrange qu'on ai besoin de tout ça ! et d'un autre côté non, car le dotnet cli a besoin d'un feed.

après faudrait voir pour articuler tout ça, quand on a internet ou pas, du coup tet simplement sur le build.ps1 ajouter un param avec un validateset ["OffLineBuild","OnlineBuild"] ... !

Du coup voila l'arbo sur ma sandbox:

le fameux fichier de conf, et le rep packages avec tous les packages nuget que j'ai dll [edit] de mon côté ça build correctement. Pour rappel il faut le client dotnet dotnet-sdk-3.1.409-win-x64.exe dispo ici : https://dotnet.microsoft.com/download/dotnet/3.1

[LxLeChat]

Ajotuer un dotnet clean avant de restore ou de build, comme cela ça clean les répertoire d'output

[LaurentDardenne]

>>si tu ne veux pas à avoir a dll la liste de fichier, je peux éventuellement la déposer sur le repo en zip Non pas nécessaire on doit de toute façon accéder à internet pour récupérer le projet. Je testerais ce projet.

[LxLeChat]

ouais j'ai vu nusave, à priori c'est le même principe .. ! mais pas sur que ça fonctionne. (intéresser par tes résultats en tout cas ) ça fait ajotuer une dépendance en revanche nusave !

Dans tous les cas si la personne veut build en offline et qu'il n'a pas nusave, il aura besoin de tous les package nuget, donc c mieux de les avoir sous la main ... je vais modifier le script de build pour ajouter une option de build offline, modifier la doc aussi.

[LaurentDardenne]

ça ajoute une dépendance en revanche nusave !

Un lien, un script et bout de doc suffise. Après chacun se débrouille.

[LxLeChat]

t as pas tord :) bah tient au jus sur tes découvertes !

[LxLeChat]

pour info il y a un zip package.zip je crois sur la branch master qui contient tout les paquet nuget nécessaires ... j avais oublié de l exclure lors du dernier merge ... -_-

[LaurentDardenne]

Résultat des courses : pour différentes raisons (flux fermé, pas de droits admin sur le poste), je n'ai pas pu télécharger la liste de packages. Et NuSave est compilé avec dotnet 5.0 ...

J'ai donc copié le zip du projet sur le serveur et ai utilisé l'archive indiquée. Auparavant j'ai créé sur ce serveur un répertoire local et configurer VS :

J'ai ensuite installer tous les pkg avec :

cd C:\Users\monCompte\Downloads\FlowChartCore\Src\Packages
dir *.nupkg |% { C:\Tools\Development\Nuget\nuget.exe add "$_" -source E:\projets\nuget }

Une fois ceci fait (après 1 heure de traitement, cette commande nuget étant très longue à s'exécuter sur mon serveur) j'ai pu compiler le projet avec VS Community 2019 en ayant au préalable chargé toutes les dépendances via un menu contextuel de l'explorateur de projet.

Pour le warning j'ai ajouté ceci dans le fichier projet :

  <PropertyGroup>
    <TargetFrameworks>netcoreapp3.1;netstandard2.0</TargetFrameworks>
     <nowarn>NU1603</nowarn>
  </PropertyGroup>

Demain je supprime tout et recommence en ligne de commande.

Comment as-tu construit la liste des pkg dépendants (insérés dans l'archive) ?

[LxLeChat]

j'allais dire: c'est le seul truc que je n'ai pas noté ... mais ayé ça m'est revenu :) à l'arrache !

cad : j'ai lancé un dotnet build, et j'ai parsé les erreurs à coup d'expessions régulières .. et j'ai ajouté les paquets petit à petit (en commençant par system.automation.management.nupkg et dotnetgraph.nupkg, et apres il m'a dit qu'il manquait plein d'autres trucs ...) il y a surement une meilleur méthode mais bon ... j'ai trouvé que la regex c'était plus rapide que de chercher sur internet xD

[LaurentDardenne]

Après avoir cherché pendant une heure j'ai trouvé l'info.

Pour lister les pkg dépendants il existe le fichier project.assets.json :

cd C:\Users\COMPTE\Downloads\FlowChartCore\Src\obj

$project=(gc .\project.assets.json)|ConvertFrom-Json

$Packages=$project.targets.'.NETCoreApp,Version=v3.1'

$Packages.psobject.Properties.Name #ou $Project.libraries.psobject.properties.name

#La première ligne (header) utilise aussi le même délimiteur
$Dependencies=@('"Name"/"Version"',( $Packages.psobject.Properties.Name) )|ConvertFrom-Csv -Delimiter '/'

# on obtient des PSobjects (‘Name’,’version’)
$Dependencies
# selon la plateforme  il manque 
 #   'netstandard.library.2.0.3.nupkg'
#   'powershellstandard.library.5.1.0.nupkg'

On peut vouloir aller plus loin afin de faciliter le téléchargement :

#création d'un metapackage
cd ..
#C:\Users\COMPTE\Downloads\FlowChartCore\Src\
md nuspec

#need XMLObject -> https://www.myget.org/gallery/ottomatt
IPMO PSNuspec
$Sb=[scriptblock]::Create(@"
    properties @{
       Description='Liste des packages pour une installation offline'
       Authors='LD, LxLechat'
    }

    dependencies {
       $(
                      Foreach ($Pkg in $Dependencies)
                      { "       dependency '{0}' '{1}'`r`n" -F $Pkg.Name,$Pkg.Version }
       )
    }
"@)

Nuspec 'MetaPackageFlowChartCore' '1.0' $sb|
Save-Nuspec -FileName C:\Users\COMPTE\Downloads\FlowChartCore\Src\obj\Nuspec\Test.nuspec

On obtient ceci :

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>MetaPackageFlowChartCore</id>
    <version>1.0</version>
    <authors>LD, FxLchat</authors>
    <description>Liste des packages pour une installation offline</description>
    <dependencies>
      <dependency id="DotNetGraph" version="2.6.0" />
      <dependency id="Microsoft.ApplicationInsights" version="2.13.1" />
…
      <dependency id="System.Windows.Extensions" version="4.7.0" />
    </dependencies>
  </metadata>
</package>

Ensuite on crée le pkg nuget :

E:\SYSTOOLS\Development\Nuget\nuget.exe pack C:\Users\COMPTE\Downloads\FlowChartCore\Src\obj\Nuspec\Test.nuspec -Verbosity detailed
#...
#Successfully created package 'C:\Users\COMPTE\Downloads\FlowChartCore\Src\MetaPackageFlowChartCore.1.0.0.nupkg'.

Le fichier généré fait 3 Ko, reste à le placer sur un serveur Nuget ou Myget si on ne veut pas ‘polluer’ le serveur officiel. Il me reste à regarder si ceci ne serait pas plus approprié : https://docs.microsoft.com/en-us/nuget/reference/packages-config

Ceci dit il reste possible de télécharger la liste des pkg via Nuget Install … Ce n’était pas l’objectif mais on peut avoir besoin de cette méthode chez certains clients.

[LxLeChat]

super cool les recherches !!!! j'avais pas vu le fichier Assets ... effectivement y a tout dedans xD donc toi tu proposes d'avoir un package qui contient tous les package si jai bien compris ?

mais du coup tu proposes de faire comment au build exactement ?? je suis un peu perdu la pour le coup ... :)

avec ma solution on a "juste" a spécifier un fichier custo qui pointe sur la source des paquets (évidement je me rends bien compte que ça pose problème, car le chemin sera différent sur mon PC et sur le tient, maus que vu que c du XML c'est plutot simple à modifier) avec ta solution ça semble aussi simple puisque tu as tous les packages regroupés dans un metapackage (et léger de surcroit..) mais comment on l utilise pour le build ???

je serai du coup interesser de voir comment on fait avec ta solution, j'avais commencé à faire ça, et ça fonctionne sur une machine offline:

## build offline, configuration offline packages & config file
Set-Location -Path .\Src
remove-item .\Packages\* -Recurse
Expand-Archive .\resources\Packages.zip -DestinationPath .\Packages

## Change Config file to match nuget.config file full path relative to your environnement
[xml]$NugetConfig = Get-Content .\packages\nuget.config
$NugetConfig.configuration.packageSources.add.value = "$($(Get-Item .\packages\nuget.config).Directory)"
$NugetConfig.Save($(get-item .\packages\nuget.config).FullName)

dotnet build --configfile .\packages\nuget.config /nowarn:NU1603

what do you think ? je suis tout à fait ouvert à l'idée d'utiliser une autre méthode !

pour un info j'ai pas vs community, j'utilise vscode du coup y a des trucs qui doivent surement changé ... !!! et surtout tu dois avoir des possibilités que je n'ai pas avec vscode

[LaurentDardenne]

je suis un peu perdu la pour le coup ... :)

Le méta package c'était juste pour le offline. Je suis allé plus loin dans la démarche, mais pour le build ce n'est pas nécessaire en tout cas pas pour le moment et ce serait un script séparé du build.

j'utilise vscode du coup y a des trucs qui doivent surement changé

C'est pour cela que la construction doit se baser sur l'outil du framework dotnet.exe et rester indépendant de l'IDE.

évidement je me rends bien compte que ça pose problème, car le chemin sera différent sur mon PC et sur le tien.

Pour le offline peut être, mais je n'ai pas continué dans cette voie, je voulais juste savoir comment faire au cas où. Pour le build du projet (avec une connexion internet donc) il faut utiliser un répertoire commun basé sur une variable d'environnement. Par exemple $env:\Temp, ensuite un sous répertoire de livraison $env:\Temp\Releases et enfin celui du projet $env:\Temp\Releases\FlowchartCode.

J'essaie de créer une PR ce WE pour une démo de build adapté de celui que j'utilise sur mon projet actuel. Le script de démarrage qui appel un script de tâches InvokeBuild :

#Requires -Modules InvokeBuild

[CmdletBinding(DefaultParameterSetName = "Debug")]
Param(
    [Parameter(ParameterSetName="Release")]
  [switch] $Release,

  [ValidateRange('Dev','Prod')]
  [string] $Environnement='Dev'
)

Write-Host "Construction de la livraison XYZ."
$local:Verbose=$PSBoundParameters.ContainsKey('Verbose')
$local:Debug=$($PSBoundParameters.ContainsKey('Debug'))
Invoke-Build -File "$PSScriptRoot\Projet.build.ps1" -Configuration $PsCmdlet.ParameterSetName -Environnement $Environnement -Verbose:$Verbose -Debug:$Debug

Et pour récupèrer les dernières sources avant le build :

[CmdletBinding(DefaultParameterSetName = "Debug")]
Param(
   #On propage la configuration demandée au script de build
    [Parameter(ParameterSetName="Release")]
  [switch] $Release,

  [ValidateRange('Dev','Prod')]
  [string] $environnement='Dev'
)

$RepositoryName='XYZ' # $Env:...
# $GitHubUserName='User'
# $Organisation='open source'

try
{
  Push-Location $env:Temp > $null

  if ( Test-Path $RepositoryName -PathType Container)
  { Remove-Item $RepositoryName -Recurse -Force }

  if (Get-Command 'Git.exe' -ErrorAction Stop)
  {
    #pour Github Enterprise avec authentification (token)
    # Git clone --branch=master https://${GitHubUserName}@github.ENTERPRISE-URL.com/${Organisation}/${RepositoryName}.git

    Write-Host "Récupération des sources du projet '$RepositoryName' dans '$env:Temp\$RepositoryName'"
    Git clone --branch=master https://URL github\XYZ.git

    Write-Host 'Supprime le versionning de ce répertoire'
    Remove-Item $env:Temp\$RepositoryName\.git -Recurse -Force
  }

  Set-Location "$env:Temp\$RepositoryName" >$null

  # Appel du script de build avec la configuration demandée.
  . .\Build.ps1 @PSBoundParameters

}
finally
{ Pop-Location }

[LxLeChat]

ok pas de soucis ! je vais juste merge les modif de la branche digraphname dans le master! donc fait gaffe ! j avais fait des modifs dans le builds.ps1 mais du coup je les ai commenté

[LaurentDardenne]

Tu peux clore, le sujet du build nécessite une autre issue je pense.

J'essaie de créer une PR ce WE

Les tâches que j'utilise ne sont pas adaptées à ce type de projet, j'ai bcp de contrôles/tâches que tu n'utilises pas ou qui n'ont pas lieu d'être ici. Je dois simplifier tout en permettant de possibles ajouts si besoin.

Le projet d'origine : https://github.com/PowerShellOrg/Plaster/issues/ 145 La liste des tâches. De mon côté j'y ai ajouté le contrôle de l'encodage, des fichiers de localisation, d'un 'pseudo-préprocesseur'. Ce qui fait que le fichier de configuration peut contenir bcp d'infos et être 'indigeste'.

Le script de build existant construit les dll et enchaîne les tests, l'objectif étant la construction du package à publier.

[LxLeChat]

Ah oui c'est costaud ! je ne suis jamais allé aussi loin ... ! c'est interessant .. j'ai l impression d'être complètement à l'ouest quand je vois ça ^^ on se sent petit ... !

Le script de build existant construit les dll et enchaîne les tests, l'objectif étant la construction du package à publier.

[LaurentDardenne]

Une représentation DGML :

Visual Studio Community permet de charger ce type de document, on peut donc réorganiser le graphe.