I am trying to publish a new version of a Powershell module to the Powershell Gallery by using
Publish-Module -Name "Nuttercode-PRTG" -NuGetApiKey $apiKey -Verbose -RequiredVersion 1.4
The module .psm1 and .psd1 files can be found here.
After dotnet.exe created the package in {myUserDir}\AppData\Local\Temp\{random numbers}\Nuttercode-PRTG it reports:
VERBOSE: finished running C:\Program Files\dotnet\dotnet.exe with exit code 0
VERBOSE: Created Nuget Package
VERBOSE: Successfully created nuget package at
Write-Error: Failed to publish module 'Nuttercode-PRTG': 'Cannot bind argument to parameter 'NupkgPath' because it is an empty string.'.
Afterwards the temp-folder gets deleted. To me this sounds like an internal problem of Publish-Module or dotnet.exe, but I have no idea what is going on or if I am doing something very wrong myself. I also created a new api key just in case but it did not affect the result.
I am using Windows 10 20H2 (Build 19042.1469), Powershell 7.2.2, PowerShellGet 2.2.5, and dotnet.exe 6.0.201. I am able to replicate the problem on another computer using the same command and arguments using Windows 11 21H2 (Build 22000.556), Powershell 7.2.1, PowershellGet 2.2.5, and dotnet.exe 5.0.102.
Related
I am trying to extract a site template of our site(based on the Communication site template) and restore it onto a new one. Whenever I run the below command, I am seeing an error as below
Get-PnPSiteTemplate -Out "C:\bin\ONNProd.xml" -Handlers PageContents,Lists,Pages,Theme,Fields -IncludeAllPages
Get-PnPSiteTemplate : Method not found: 'System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable`1<Boolean> Enumerator.MoveNextAsync()'.
Checking the version of PnP.Powershell using
Get-Module -Name PnP.PowerShell gives me as 1.7.0
Can some one help me what am i missing?
If you are using VSCode, this could be a bug with the Powershell extension as laid out here https://github.com/microsoft/vscode/issues/120026
I had the same issue, but when running the code from Powershell ISE, it is running now
Sounds like there is a bug with the most recent version (v1.7 and possible v1.6) of PNP.PowerShell for this function. I was able to successfully get this to run by installing the 1.5 version.
Run this to install:
Install-Module PNP.PowerShell -RequiredVersion 1.5.0 -AllowClobber
I have recently upgraded some of our windows application to VS2019 and created the setup project using VSInstallerProject extension in VS2019 . What I noticed is setup is not getting created when the Release pipeline is run , but I need the msi (or exe) files here so I can use the same to install on app server .
I have made changes in my pipeline and added a task : 'DutchWorkz - Build VS Installer(s)' in the release pipeline .
I have attached the logs of the error I am getting at this task in Azure Devops below .
Build is getting failed at this task .
Can anyone guide me on what the issue here is and how can I resolve it ?
Also , I want to create the setup projects/msi in VS2019 , but I don't see Vs2019 option in this task,
how can I use this task in VS2019 version .I have Vs2019 installed on agent server .
2020-09-21T20:04:43.3394997Z ##[section]Starting: Create .msi file(s) from VS Installer project(s).
2020-09-21T20:04:43.3539534Z ==============================================================================
2020-09-21T20:04:43.3539958Z Task : DutchWorkz - Build VS Installer(s)
2020-09-21T20:04:43.3540023Z Description : Build .msi file(s) from VS Installer project(s).
2020-09-21T20:04:43.3540076Z Version : 1.2.4
2020-09-21T20:04:43.3540129Z Author : DutchWorkz B.V.
2020-09-21T20:04:43.3540201Z Help : <b>BuildVsInstaller v1.2.4</b>, DutchWorkz B.V. (Robin Paardekam)<br/><br/>Visual Studio Installer projects are not supported by MSBUILD, so a regular build will not generate your installer files (.msi). Use this build-task to build the .msi file(s) for your project by running devenv on the buildagent directly. <br/><br/><b>Dependencies:</b><br/>Dep1: when using VisualStudio 2017, this task will only function properly if you installed it in the default C:\Program Files (x86)\ location.
2020-09-21T20:04:43.3540311Z ==============================================================================
2020-09-21T20:05:07.5667900Z DEBUG: Aggregated: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com
2020-09-21T20:05:07.5714835Z Now running (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com) with Arguments ("D:\VSTS Agent Folder\SO\6\s\SOApplications.sln" /Build "release|any cpu" /Project "D:\VSTS Agent Folder\SO\6\s\App_Tool_Installer\App_Tool_Installer.vdproj" /Out "D:\VSTS Agent Folder\SO\6\b\BuildInstaller_Log_20200921200507.txt")
2020-09-21T20:05:15.0213322Z Done running DevEnv process. Success = False.
2020-09-21T20:05:15.0238151Z ##[error]Unable to process command '##vso[task.addattachment type=Distributedtask.Core.Summary;name=Installer project errors;]D:\VSTS Agent Folder\SO\6\b\BuildInstaller_Log_20200921200507.txt' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
2020-09-21T20:05:15.0239574Z ##[error]Cannot upload task attachment file, attachment file location is not specified or attachment file not exist on disk
2020-09-21T20:05:15.1116369Z Attachment added: Log file for Installer generation.
2020-09-21T20:05:15.1928578Z ##[error]An error occurred while running DevEnv! Please review logfile BuildInstaller_Log_20200921200507.txt
2020-09-21T20:05:15.2720322Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
I have tried using devenv command line too , inorder to build the setup project .I have tried it with both the vs2017 (professional) and vs 2019(enterprise) and I am getting issue in both .While issue with 2017 is about license , I am not able to figure out what's causing the issue for 2019 . Please let me know if you have any thoughts on what could possibly be causing this issue and how can this be resolved . The goal is offcourse to build the setup project with azure devops pipeline and use the generated msi file for installation on app server .
Thanks in advance .
Here's the screenshot for new build and issue :
Build agent server has Vs installer already installed , pls see if this is okay :
Please check the new logs from 'command line task' below :
2020-09-26T16:04:39.7854210Z ##[debug]Evaluating condition for step: 'Command Line Script'
2020-09-26T16:04:39.7856182Z ##[debug]Evaluating: succeeded()
2020-09-26T16:04:39.7856654Z ##[debug]Evaluating succeeded:
2020-09-26T16:04:39.7857594Z ##[debug]=> True
2020-09-26T16:04:39.7858101Z ##[debug]Result: True
2020-09-26T16:04:39.7858600Z ##[section]Starting: Command Line Script
2020-09-26T16:04:39.8082090Z ==============================================================================
2020-09-26T16:04:39.8082357Z Task : Command line
2020-09-26T16:04:39.8082602Z Description : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
2020-09-26T16:04:39.8082847Z Version : 2.164.2
2020-09-26T16:04:39.8083025Z Author : Microsoft Corporation
2020-09-26T16:04:39.8083274Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
2020-09-26T16:04:39.8084133Z ==============================================================================
2020-09-26T16:04:39.8097829Z ##[debug]tf vc resolvePath $\CDM\Dev /loginType:OAuth /login:.,*** /noprompt
2020-09-26T16:04:40.1991127Z ##[debug]D:\VSTSAgent\sn\30\s
2020-09-26T16:04:41.0198149Z ##[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352
2020-09-26T16:04:41.1044331Z ##[debug]Entering D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\cmdline.ps1.
2020-09-26T16:04:41.1126277Z ##[debug]Loading resource strings from: D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\task.json
2020-09-26T16:04:41.1272687Z ##[debug]Loaded 6 strings.
2020-09-26T16:04:41.1306950Z ##[debug]SYSTEM_CULTURE: 'en-US'
2020-09-26T16:04:41.1325343Z ##[debug]Loading resource strings from: D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\Strings\resources.resjson\en-US\resources.resjson
2020-09-26T16:04:41.1467074Z ##[debug]Loaded 6 strings.
2020-09-26T16:04:41.1670941Z ##[debug]INPUT_FAILONSTDERR: 'false'
2020-09-26T16:04:41.1696717Z ##[debug] Converted to bool: False
2020-09-26T16:04:41.1718695Z ##[debug]INPUT_SCRIPT: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv" "D:\VSTSAgent\sn\30\s\st.sn.ComponentManagement.sln" /build release'
2020-09-26T16:04:41.1739155Z ##[debug]INPUT_WORKINGDIRECTORY: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.1861366Z ##[debug]Asserting container path exists: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.1900763Z Generating script.
2020-09-26T16:04:41.1963727Z Script contents:
2020-09-26T16:04:41.1969048Z "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv" "D:\VSTSAgent\sn\30\s\st.sn.ComponentManagement.sln" /build release
2020-09-26T16:04:41.2078510Z ##[debug]AGENT_VERSION: '2.173.0'
2020-09-26T16:04:41.2148233Z ##[debug]AGENT_TEMPDIRECTORY: 'D:\VSTSAgent\sn\_temp'
2020-09-26T16:04:41.2166134Z ##[debug]Asserting container path exists: 'D:\VSTSAgent\sn\_temp'
2020-09-26T16:04:41.2329780Z ##[debug]Asserting leaf path exists: 'C:\Windows\system32\cmd.exe'
2020-09-26T16:04:41.2337995Z ========================== Starting Command Output ===========================
2020-09-26T16:04:41.2446509Z ##[debug]Entering Invoke-VstsTool.
2020-09-26T16:04:41.2539207Z ##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "D:\VSTSAgent\sn\_temp\442cb1cb-a43b-4d2a-b036-4f16ab588410.cmd""'
2020-09-26T16:04:41.2553937Z ##[debug] FileName: 'C:\Windows\system32\cmd.exe'
2020-09-26T16:04:41.2568488Z ##[debug] WorkingDirectory: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.2608339Z ##[command]"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\VSTSAgent\sn\_temp\442cb1cb-a43b-4d2a-b036-4f16ab588410.cmd""
2020-09-26T16:04:47.9474432Z
2020-09-26T16:04:47.9514773Z Microsoft Visual Studio 2019 Version 16.7.3.
2020-09-26T16:04:47.9656002Z Copyright (C) Microsoft Corp. All rights reserved.
2020-09-26T16:04:47.9656269Z
2020-09-26T16:04:47.9656416Z The license for Visual Studio expires in 19 days.
2020-09-26T16:04:47.9656554Z
2020-09-26T16:04:47.9657872Z Some errors occurred during migration. For more information, see the migration report:
2020-09-26T16:04:47.9658144Z D:\VSTSAgent\sn\30\s\UpgradeLog2.htm
2020-09-26T16:04:50.0902169Z 1>------ Build started: Project: st.sn.ComponentManagement, Configuration: Release x86 ------
2020-09-26T16:04:52.8763939Z ========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
2020-09-26T16:04:53.4375608Z ##[debug]Exit code: 0
2020-09-26T16:04:53.4417000Z ##[debug]Leaving Invoke-VstsTool.
2020-09-26T16:04:53.4426510Z ##[debug]Leaving D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\cmdline.ps1.
2020-09-26T16:04:53.5245394Z ##[section]Finishing: Command Line Script
Here's the additional error log :
EVEN though the command line task passed , the .vdproj setup project didn't get updated or build . I can see that from timestamp , all other projects getting updated as usual .
I found a similar ticket you can refer to it.
Configure self-hosted agent and make sure the VS Installer Projects extension is installed on your own build agent and then you can build the setup project either use command line task with "devenv" or use the "Build VS Installer" task.
If you get the error like 8000000A, you can follow the instruction here to configure your self-hosted agent: Solution: An error occurred while validating. HRESULT = '8000000A'.
By the way, since this extension is developed by a third party. You can connect the extension owner to get the detail info
Update1
We can install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
I looked at the package you mentioned, at this location - https://marketplace.visualstudio.com/items?itemName=dutchworkz.BuildInstaller&ssr=false#review-details
If you go there and look at the comments other users have left behind, the error is something that is present as part of the build process. The original developer has not fixed it.
At the same, just like the users have mentioned, you are able to see the msi installer and use it. So, you are (I am assuming) getting what you need, the installer.
My best suggestion is, since you are getting what you need, ignore the error and wait till the developer fixes this issue. Until then, there is nothing you or anybody else can do about it.
Note : I also noticed that if you are using the default configuration during the build process for simple projects, it works fine. Your project and build may have some customization which is where other users have reported errors.
I'm having an issue packaging my own nuget package, which includes AutoMapper 5.0.2. This is only producing an error within the Visual Studio Team Services (VSTeam) Build servers.
My project is using .NET 4.6.1
Any ideas on how to fix?
Here is the error:
2016-07-08T23:46:44.5801667Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.102.0\agent\worker\tools\NuGet.exe pack "C:\a\1\s\Project.csproj" -OutputDirectory "C:\a\1\s\Project\bin\release" -Properties Configuration=release -IncludeReferencedProjects
2016-07-08T23:46:45.0458195Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-07-08T23:46:45.0468395Z Attempting to build package from 'Project.csproj'.
2016-07-08T23:46:45.1942694Z Packing files from 'C:\a\1\s\Project\bin\Release'.
2016-07-08T23:46:45.3942642Z ##[error]**'AutoMapper' already has a dependency defined for 'NETStandard.Library'.**
2016-07-08T23:46:45.4142626Z ##[error]System.Exception: Unexpected exit code 1 returned from tool NuGet.exe
2016-07-08T23:46:45.4152639Z ##[error] at Microsoft.TeamFoundation.DistributedTask.Task.Internal.PowerShell.InvokeToolCmdlet.ProcessRecord()
2016-07-08T23:46:45.4152639Z ##[error] at System.Management.Automation.CommandProcessor.ProcessRecord()
I also opened an issue on GitHub: https://github.com/AutoMapper/AutoMapper/issues/1499
You need to install new Nuget version for your visual studio version.
Get it from here
Nuget gallery
I was able to fix/workaround the issue by putting a PowerShell script in to download the latest NuGet. Then I pointed all of the NuGet tasks to this new nuget.exe. Pros: builds are working again, Cons: each build downloads NuGet again, causing unnecessary load on NuGet.org.
Here is my PowerShell:
$sourceNugetExe = "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe"
$targetNugetExe = "$(build.sourcesdirectory)/nuget.exe"
Invoke-WebRequest $sourceNugetExe -OutFile $targetNugetExe
Set-Alias nuget $targetNugetExe -Scope Global -Verbose
nuget
If someone using Team City you also need to use / install newer version of Nuget.
Whenever I try to open package manager console in Visual studio 2013 update 3 I get this error :
Cannot load Windows PowerShell snap-in Microsoft.PowerShell.Management because of the following error: > Could not load file or assembly
'file:///C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Microsoft.PowerShell.Commands.Management.dll' or
one of its dependencies. The system cannot find the file specified.
I have uninstalled/Re installed powershell. It didn't change anything.
any ideas?
Thank you.
I want to build my solution using psake and msbuild (v3.5) on an x64 pc. When I execute the script I get the following error:
error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The message is correct, the file is missing but I have installed the 32 bit version of VS 2008 and therefor it is in the folder 'C:\Program Files (x86)...'
Is there any solution to tell msbuild to use the 32 bit version, not the 64 bit version?
You can specify what framework version is used for build. See $framework variable. In your case you need $framework = '3.5×86' at the beginning of the script.