Je suis en train de migrer les scripts de déploiement Azure d'AzureRM vers Az et il semble que le nouveau module ait du mal à ouvrir les fichiers.
Des idées?
J'ai essayé de remplacer les barres obliques inverses par des barres obliques; Je l'ai même appelé à partir du dossier où se trouvent les scripts, donc je n'ai pas besoin de lui transmettre le nom complet du fichier, et il le résout correctement en un nom complet, mais il ne peut toujours pas l'ouvrir.
XXX
Mise à jour du 13/02/19:
J'ai créé un scénario de cas de test très simple, en dehors de notre plus grande suite de scripts et je peux très facilement recréer le problème. J'ai mis un fichier appelé test.json dans c: \, il contient un objet json vide, juste les accolades, comme vous pouvez le voir dans la sortie ci-dessous. J'utilise le scénario d'alias AzureRM:
PS C:\> type test.json
{}
PS C:\> type C:\test.json
{}
PS C:\> Enable-AzureRmAlias
PS C:\> $sa = Get-AzureRmStorageAccount -ResourceGroupName florin-rg -Name florinsa
PS C:\> Set-AzureStorageBlobContent -Container florin-container -Context $sa.Context -File test.json -Blob test
Set-AzureStorageBlobContent : Failed to open file C:\test.json: Illegal characters in path..
At line:1 char:1
+ Set-AzureStorageBlobContent -Container florin-container -Context $sa. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Set-AzStorageBlobContent], TransferException
+ FullyQualifiedErrorId : TransferException,Microsoft.WindowsAzure.Commands.Storage.Blob.SetAzureBlobContentCommand
PS C:\>
3 Réponses :
Si votre commande AzureRM fonctionne correctement, le moyen le plus simple d'exécuter la commande AzureRM avec le module Az est simplement exécuté Enable-AzureRmAlias dans un premier temps, puis exécutez votre commande AzureRM , cela fonctionnera également.
De plus, je teste le Az code> en local, cela devrait fonctionner correctement.
$context = New-AzStorageContext -StorageAccountName "<StorageAccountName>" -StorageAccountKey "xxxxxxx" Set-AzStorageBlobContent -Container "111" -File "C:\Users\joyw\Desktop\cosmos.json" -Context $context
Voici mes modules PowerShell , vous pouvez les vérifier.
Mes modules sont plus récents: Get-Module -ListAvailable Directory: C: \ Program Files \ WindowsPowerShell \ Modules ModuleType Version Name ---------- ------- ----- Script 1.2.1 Az.Accounts Script 1.0.1 Az.KeyVault Script 1.1.1 Az.Resources Script 1.1.0 Az.Sql Script 1.0.2 Az.Storage
@Florinator Je vois que vous soulevez le même problème dans github.com/Azure/azure-powershell/issues / 8473 . J'ai répondu au problème dans GitHub et j'ai besoin de plus d'informations. Voulez-vous s'il vous plaît le suivre dans GitHub?
Je viens d'essayer avec Enable-AzureRmAlias et j'obtiens la même erreur.
J'ai mis à jour ma question initiale avec un scénario de test simplifié.
@Florinator C'est bizarre. Essayez de réinstaller votre module Az et changez le chemin, C: \ est un peu spécial.
Après avoir lu la discussion sur https://github.com/Azure/azure- powershell / issues / 8473 (crédit aux commentaires ci-dessus) et en suivant le lien vers https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/09/new-net-path-handling-sneak-peek/ a > J'ai pu résoudre le problème sur ma machine. Le deuxième document lié dit: "Déposez un fichier appelé Après avoir redémarré PowerShell, j'ai pu exécuter mes scripts avec succès. Le problème a commencé après la mise à jour du module MISE À JOUR 0 Il est également possible de modifier le registre pour résoudre le problème. Ensuite, redémarrez l'instance PowerShell. powershell.exe.config dans C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 avec le contenu suivant ". J'avais déjà le fichier, j'ai donc ajouté le contenu à mon fichier existant. $registryPath = "HKLM:\SOFTWARE\Microsoft\.NETFramework\AppContext"
New-Item -Path $registryPath
New-ItemProperty -Path $registryPath -Name "Switch.System.IO.UseLegacyPathHandling" -Value "false"
Az et la suppression du module AzureRm . J'espère que cela permettra à d'autres de gagner du temps à ne pas chercher les liens. <configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
</configuration>
Cela ne peut fonctionner que si vous contrôlez l'environnement. Il ne vole pas sur un agent de construction.
Aucune des solutions ci-dessus n'a fonctionné pour moi. La seule façon de le battre était d'utiliser le module Azure.Storage au lieu de Az.Storage et Set-AzureStorageBlobContent au lieu de Set-AzStorageBlobContent
Donc:
1) Install-Module Azure.Storage -AllowClobber (sans -AllowClobber, il échoue à cause d'Azure.Profile)
2) Module d'importation Azure.Storage
3) Dans le script, remplacez la commande Set-AzStorageBlobContent par Set-AzureStorageBlobContent
Pouvez-vous l'utiliser avec d'autres modules Az?
Le chemin dans le fichier JSON est-il simplement un chemin de disque?
Oui. Et j'ai essayé différentes manières, chemin relatif, chemin absolu, il résout correctement le nom complet, mais ne parvient pas à l'ouvrir. BTW, cette même partie fonctionnait bien avec la version AzureRM, donc je suis plutôt convaincu qu'il n'y a rien de mal avec le chemin lui-même.
Est-il possible qu'il n'aime pas les virgules ou les deux points dans le fichier JSON? Un rapide google n'a rien révélé de significatif. À titre de test, pourriez-vous utiliser un fichier JSON différent avec une seule ligne pour voir si peut-être un crochet, deux points ou une virgule fait aboyer l'interpréteur?
Je vais essayer, bien que le message d'erreur indique «Caractères illégaux dans PATH». J'ai supposé que c'était mon chemin de fichier ...
Je ne suis pas familier avec les commandes Azure, mais je suppose qu'il y a quelque chose dans le JSON qui ne lui plaît pas. Avoir rencontré des problèmes similaires avec l'automatisation des configurations JSON auparavant, mais purement une supposition d'ici
Essayé avec un fichier json vide, essayé avec un fichier contenant uniquement {}, même erreur, impossible d'ouvrir le fichier.
L'erreur semble se plaindre du nom du fichier, pas du contenu.
continuons cette discussion dans le chat .