I'm scripting the update of some nuget packages to my shared folder (MSBuild 15):
\\myserver\packages
I changed the Windows User that have access to this shared folder to be: NugetUser.
I can access the share from Explorer, using the NugetUser credentials.
But when I use:
nuget add new_package.1.0.0.nupkg -source \\myserver\packages
or:
nuget init c:\packages \\myserver\packages
I cannot drop the packages on the share because I have no permission. How can I specify the user from the script?
My script is a simple batch file:
#echo off
nuget init .\packages \\myserver\packages
:END
echo "End"
pause
I found following solution:
#echo off
net use \\myserver\packages /user:myserver\User password
nuget init .\packages \\myserver\packages
:END
echo "End"
pause
Related
While trying to add authentication to a .net core app on mac, using this command :
dotnet aspnet-codegenerator identity -h
I receive this error :
Macintosh-2:Website abd$ dotnet aspnet-codegenerator identity -h A
fatal error occurred, the required library libhostfxr.dylib could not
be found. If this is a self-contained application, that library should
exist in
[/Users/abd/.dotnet/tools/.store/dotnet-aspnet-codegenerator/2.2.3/dotnet-aspnet-codegenerator/2.2.3/tools/netcoreapp2.1/any/].
If this is a framework-dependent application, install the runtime in
the default location [/usr/local/share/dotnet] or use the DOTNET_ROOT
environment variable to specify the runtime location. M
For Mac M1 processor, the .NET libraries are not located in the default install location "usr/local/share/dotnet"; but rather in one of its sub-directories "./x64".
You have to set the DOTNET_ROOT environment variable to point to that sub-directory.
export DOTNET_ROOT=/usr/local/share/dotnet/x64
I guess this same solution could be scaled beyond the M1 processor, so long you set DOTNET_ROOT to whatever directory contains libhostfxr.xx
Dotnet executable will be present at $DOTNET_ROOT which you can find with which dotnet or
readlink $(which dotnet)
A successful dotnet installation will have the libhostfxr.dylib file at $DOTNET_ROOT/host/fxr/$version/
If so, it is a permission issue and running with sudo will do.
sudo dotnet aspnet-codegenerator identity -h
Ref
I ran into this same issue with running the Omnisharp language server on an M1 Mac. The solution for me was to set the DOTNET_ROOT environment variable to the correct global dotnet location. For me this was /usr/local/share/dotnet.
I also needed to update the contents of /etc/dotnet/install_location. I noticed that there were two files in /etc/dotnet.
install_location
install_location_arm64
The install_location_arm64 contained the correct path to dotnet (/usr/local/share/dotnet), but install_location contained /usr/local/share/dotnet/x64 which doesn't exist. After updating the contents of install_location to /usr/local/share/dotnet, the problem was solved for me.
This solved it for me:
dotnet tool uninstall dotnet-ef --global
dotnet tool install dotnet-ef --global -a arm64
if you have installed/uninstalled .net frameworks on your machine maybe the links are looking in the wrong folder.
check dotnet location with the command which dotnet
eg the location should be something like that:
/usr/local/share/dotnet/dotnet
Afterwards, check the file /etc/dotnet/install_location
should contain one line with the above path.
I'm trying to execute msbuild on Azure Devops. Because of that I cannot use the MSBuild task provided.
When I use a Command Line task the command is not recognised. On my local machine I load vcvarsall.bat before I use msbuild. But I've not been unable to work out how to obtain that path in Azure Devops. Doesn't appear to be a Develop Command Prompt task for Azue Devops either.
Any ideas on how I can use msbuild from a Command Line task or Batch Script task? Using their Hosted VS agent.
The best way to do this in a supported way is to use vswhere. The following bit of script will install vswhere (using chocolatey) and then query the installer registry where msbuild can be found. Replace -latest with a more specific version if you need that:
choco install vswhere
for /f "tokens=*" %%i in ('vswhere -latest -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe -nologo') do set msbuildpath="%%i"
echo "##vso[task.setvariable variable=msbuildpath]%msbuildpath%"
This will save the path to msbuild to the environment variable %msbuildpath% as well as the pipeline variable (for this stage) $(msbuildpath).
You can then either use a second run commandline task and pass in $(msbuildpath) or you can simply call MsBuild from the same piece of script mentioned above by calling:
%msbuildpath%
This will make sure your script will remain working, even if Microsoft upgrades their images and moves some things around (which does happen).
You can also get vswhere using wget or invoke-webrequest -outfile from the following location:
https://github.com/Microsoft/vswhere/releases/latest/download/vswhere.exe
Other samples for vswhere syntax can be found on the project wiki, including the syntax for PowerShell.
If you use Hosted Agent 2017 you can run the msbuild.exe from the Command Line task in this way:
Command Line version 1:
Command Line version 2:
Results:
If you are interested in seeing how the built-in Microsoft task resolves the path, all the Azure Devops tasks are provided open-source. These are the path functions you probably care to review.
Here is the solution I came up with using only built-in pipeline tasks which makes the MSBuild bin directory available on the path environment variable.
Create a PowerShell task to generate an MSBuild project to capture and output to a file the variables you are interested in (ex. MSBuildBinPath)
PowerShell script
"<Project DefaultTargets=`"DetectMsBuild`">
<ItemGroup>
<OutFile Include=`"`$(MsBuildDetectionFile)`" />
<OutFile Condition=`"'`$(OutFile)' == ''`" Include=`"msbuildInfo.json`" />
</ItemGroup>
<Target Name=`"DetectMsBuild`">
<PropertyGroup>
<MsBuildPaths>
[{
`"Name`": `"BinPath`",
`"Value`": `"`$(MSBuildBinPath.Replace('\', '\\'))`"
}]
</MsBuildPaths>
</PropertyGroup>
<WriteLinesToFile
File=`"#(Outfile)`"
Lines=`"`$(MsBuildPaths)`"
Overwrite=`"true`"
Encoding=`"UTF-8`" />
</Target>
</Project>" | Out-File -FilePath "msbuilddetect.proj" -Encoding utf8
Set the working directory and any variables accordingly.
PowerShell task settings screenshot:
Create an MSBuild task to run the project file generated by the previous task. Ensure the MSBuild version is set to the version you want to use.
MSBuild task settings screenshot:
Last, create another PowerShell task that will parse the outputted JSON file of the extracted variables and sets environment variables accordingly.
PowerShell script
Write-Host "Current path: $($env.Path)`n`n"
$msBuildVariables = Get-Content -Path msbuildInfo.json | ConvertFrom-Json
$Path = "$($msBuildVariables[0].Value);$($env:Path)"
Write-Host "##vso[task.setvariable variable=Path;]$Path"
PowerShell task settings screenshot:
Here is a screenshot of the task order in the build pipeline.
We try to migrate our old XAML build to new build system with task on on-premise TFS2015 Update1. In XAML build we have step where we check-out some files do some modification and do check-in. I found powershell helper where is connection to TFS. Than I can check-out files, get list of pending check-out, but cannot do check-in. When I call
$tfsProvider.Workspace.CheckIn($pendingChanges, "some text")
I get error
Exception calling "CheckIn" with "2" argument(s): "Could not load file or assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
I think problem is that assembly Microsoft.TeamFoundation.VersionControl.Client.dll depends on assembly Microsoft.TeamFoundation.WorkItemTracking.Client. But this assembly is not in Agent worker folder. Is only way to get this assembly to copy to agent folder or install VS2015 on machine with agent and load assembly from VS folder?
Thanks
Regards
If you want to use TFS API to check in, the assemblies must be installed on the Machine and you must import them in your PowerShell script.
Other ways to check in files would be:
With PowerShell:
You can install TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for details:PowerShell and TFS: The Basics and Beyond
With Batch Script:
You can install Team Explorer on the machine and use TF Checkin command to check in the files.
Edit the build worspace files and use tf commnads in custom/powershell task eq.
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Catch the TF.exe out it could report the errors event if everyting is ok.
Just like you said，you must make sure your build agent has the same environment with your dev machine.
The simple way is to copy the dll file on the agent folder. Or you can use Nuget to Install-Package. Suggest you to install VS2015.
I'm trying to get a Lightswitch Project into Teamcity and have tried the following runner types:
Visual Studio (sln)
MSBuild
Command line (ran MSBuild through the command line)
All 3 runner types gave me the same error when building the Lightswitch solution:
The "UnpackExtensionsToProjectDir" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object.
Lightswitch has already been installed on the server. Have tried building the solution manually using Visual Studio on the server and it builds fine. Have also tried building the solution via the command line (using MSBuild) and it builds fine too.
Would like to ask if somebody was able to get Lightswitch building nicely on TeamCity. Cheers.
This is how you build via the Command line (using TeamCity)
Pre-requisites)
First make sure you have not checked in the extensions directory, this can cause issues when building.
Check that you have installed any visual studio extensions on the build machine .ie ExtensionsMadeEasy. You can test this by opening the solution in visual studio on the build machine and trying to do a build.
Lastly, in TeamCity do not use the msbuild task, use command line to call msbuild.
Step 1)
msbuild.exe mylightswitchproject.lsproj /p:OutDir=C:\test\stuff\;configuration=Release
Step 2)
Create a bat file to copy your output to the correct folder structure.
robocopy C:\test\stuff\bin C:\test\localrelease\bin *.* /MIR
robocopy C:\test\stuff\Resources C:\test\localrelease\Resources *.* /MIR
robocopy C:\test\stuff\Web C:\test\localrelease\Web *.* /MIR
robocopy C:\test\stuff\ C:\test\localrelease\ ClientAccessPolicy.xml
robocopy C:\test\stuff\ C:\test\localrelease\ default.htm
robocopy C:\test\stuff\ C:\test\localrelease\ Home.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Login.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ LogOff.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Silverlight.js
robocopy C:\test\stuff\ C:\test\localrelease\ web.config
You can now take this folder and release it to the next environment.
Finally, if you want to create a web deployment package, out the box visual studio 2010 does not support this. However, you can copy this into an existing website then "Export" your application into a package that is then ready for web deployment via powershell.
The previous answers didn't work for us but Yaegor's answer provided some direction.
The issue we had was extensions are installed at the user level, not the system level. This meant the MSBuild process could not find the required extensions.
Our solution was to use a user account on the build server, log into account, setup VS.NET such that the LS project builds, and then switch the TeamCity agent service to use the new user account.
With this we were able to use the Solution runner (which is preferable to the CLI runner since it provides better logging and reporting).
For not Lightswitch-specific part: If command line works from console, but fails in TeamCity, most probably the issue is in the user or running as a service. You might try running TeamCity agent with the same environment.
When command line works you can then try MSBuild and Solution runners.
I ran into the same error when trying to set up an automated build for a lightswitch application using bamboo. Turned out to be the version of msbuild being called. If the 64bit version is called (from bamboo or the command line) I get the error:
UnpackExtensionsToProjectDir" task failed unexpectedly.
Switching to the 32bit version of msbuild fixes the problem.
32bit Path: 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe'
64bit Path: 'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe'
I have a project that has a post-build event that xcopies a DLLs to a certain directory:
xcopy "$(TargetDir)$(TargetName).dll" "$(SolutionDir)..\UdpLocationService\bin\Plugins\" /d /y
xcopy "$(TargetDir)$(TargetName).pdb" "$(SolutionDir)..\UdpLocationService\bin\Plugins\" /d /y
However, I have CruiseControl.NET set up as a build server and MSBuild is failing on building that project due to this xcopy post-build event:
MSB3073: The command "xcopy "C:\Build\Services\Windows\VehicleServer\Plugins\Payload\bin\Debug\Payload.dll" "*Undefined*..\UdpLocationService\bin\Plugins\" /d /y xcopy "C:\Build\Services\Windows\VehicleServer\Plugins\Payload\bin\Debug\Payload.pdb" "*Undefined*..\UdpLocationService\bin\Plugins\" /d /y" exited with code 4. in Microsoft.Common.targets(3397, 13)
Any suggestions to get this fixed?
I just ran into the same problem with TeamCity.
The issue here is the $(SolutionDir) property in your build file. You haven't defined it in your call to MsBuild (this is why you see the word undefined in your output).
Call msbuild with the property set, like this:
msbuild myproject.csproj /property:SolutionDir="solution directory"\
Where "solution directory" is the directory containing your solution file. Note the trailing slash, you'll need that to make sure the path is correctly formed.
I fixed this for problems with the Microsoft.SqlServer.Compact nuget package (which adds a similar post-build script), by adding:
<SolutionDir Condition="'$(SolutionDir)'=='' or '$(SolutionDir)'=='*Undefined*'">..\</SolutionDir>
right above the <PostBuildEvent>. You'll want to adjust the relative path to match your project layout.
Follow these steps:
Unload your project file (e.g. *.csproj)
Open your project file for editing
Find the AfterBuild target
Separate out the two invocations of XCopy into two distinct Exec tasks
Save your changes and Reload your project file