Cake NuGetRestore always wants MSBuild14? - cakebuild

While trying to rig up a solution to build with Cake v0.19.1 on a machine that has only ever known Visual Studio 2017, I can't seem to get NuGetRestore to accept a setting of MSBuildVersion = NuGetMSBuildVersion.MSBuild15.
Is there some magic step to getting a specific MSBuild version into NuGetRestore that I am missing?
Output
...
========================================
RestoreNuGet
========================================
Executing task: RestoreNuGet
Failed to load msbuild Toolset
Could not load file or assembly 'Microsoft.Build, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
An error occurred when executing task 'RestoreNuGet'.
Error: NuGet: Process returned an error (exit code 1).
Trimmed-down build.cake
var target = Argument("target", "Default");
var solution = "./some-random.sln";
Task("Default")
.Does(() => {
NuGetRestore(
solution,
new NuGetRestoreSettings {
MSBuildVersion = NuGetMSBuildVersion.MSBuild15,
}
);
});
RunTarget(target);
Update: getting NuGet v4
Per #devlead's answer, I pointed the build.ps1 file at the v4.0.0 of NuGet and got this output.
Cannot find the specified version of msbuild: '15'
An error occurred when executing task 'RestoreNuGet'.
Error: NuGet: Process returned an error (exit code 1).
In my full build.cake, I use vswhere for later MSBuildSettings which I can get to dump out the MSBuild path it found (and I confirmed that exe exists in Explorer).
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/amd64/MSBuild.exe

What you could try is to use the MSBuild alias with the restore target, latest version of MSBuild should have build in NuGet support.
MSBuild(
"./some.sln",
configurator => configurator.WithTarget("restore"));

Make sure you're using the latest version of NuGet.exe, currently it's
v4.0.0 which is the latest version, but you can also see a list of available at https://dist.nuget.org
If you're using the default build.ps1 you could modify it to always download specific version of NuGet.exe
You can do this be remove the Test.Path parts - so it won't look for nuget.exe any where else but your tools folder.
Then change the download uri to not use latest stable (currently v3.5.0) but a specific version by in build.ps1 changing
$NUGET_URL = "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe"
to
$NUGET_URL = "https://dist.nuget.org/win-x86-commandline/v4.0.0/nuget.exe"
will ensure you always download v4.0.0 of the exe.
It's also possible with a little PowerShell to verify correct version in tools, example
if ((Get-ChildItem $NUGET_EXE `
| % VersionInfo `
| % ProductVersion `
| ? { $_ -eq '4.0.0' }|Measure-Object).Count -eq 1)
{
'Correct version'
} else {
'Incorrect version'
}

Related

How do you get a grunt error to return on a VSTS hosted build agent

I'm trying to run grunt tasks through a batch script and am calling grunt as follows:
call npm install
call npm install grunt
However, if this returns an error, then the VSTS build on the hosted build agent still shows up as successful (even with a logged error in the script). Does anyone have any good examples of how to get it to return an error to the build?
I've been looking at using powershell, but without any luck so far, with code as follows:
In gruntfile.js:
grunt.initConfig({
shell: {
ps: {
options: {
stdout: true
},
command: 'powershell ../../errors.ps1'
}
}
});
grunt.registerTask('default', function() {
try {
grunt.task.run([
'less:desktop',
'less:tablet',
'less:smartphone',
'less:homepage_desktop',
'less:homepage_tablet']);
} catch(e) {
grunt.task.run([
'shell:ps']);
throw e;
}
});
In errors.ps1:
$URL_Format_Error = [string]"Error found in running grunt. Please investigate grunt logs"
Write-Error $URL_Format_Error -ErrorAction:Stop
return
The code run in the exception handler never gets called, and a warning is output with a compilation error in the .less file, but the powershell is never run. Is there a way I can hook into the warning perhaps, and run my powershell then?
As an alternative, when I try to add a grunt task to the VSTS build definition after a batch script to run the NPM install, I just keep getting the following error (even after seeing a successful NPM installation in the batch script):
Fatal error: Unable to find local grunt
Hence, I'm not sure if I can run the grunt task in a separate task the VSTS build definition, if I'm using a hosted build agent. I'm inclined to think that would only work if I had my own build server.
Just try to use Write-Error in combination with an exit 1 in your script.
Write-Error ("Some error")
exit 1
Reference this thread : How to fail the build from a PowerShell task in TFS 2015

DB2 with .NET Core 2.1

I installed IBM.Data.DB2.Core Version (1.2.2.100) with Visual Studio 2017 & .Net Core 2.1. I was trying to test simple DB2 (z/OS server) connection and getting the below error. Our DB2 Server type is OS390 and version is 11.
ERROR [42968] [IBM] SQL1598N An attempt to connect to the database server failed because of a licensing problem.
using (DB2Connection con = new DB2Connection("Server=xxxx.xxxx.com:446;Database=XXXX;UID=XXXXXX;PWD=xxxxx"))
{
try
{
con.Open();
}
catch (Exception ex)
{
throw ex;
}
}
Also I copied the license file to .nuget\packages\ibm.data.db2.core\1.2.2.100\build\clidriver\license folder.
I tried everything mentioned here:
https://www.ibm.com/developerworks/community/blogs/96960515-2ea1-4391-8170-b0515d08e4da/entry/Instructions_for_downloading_and_using_DB2_NET_Core_provider_package?lang=en
Any thoughts?
Spent a few hours on this and here is what worked for me using current latest version of the package 1.3.0.100 and a valid DB2 11.1 license I already had installed. I suspect this approach will work on 1.1 and 1.2 as well, assuming you have the license already.
Add the following block to your project file, adjusting the path for DB2License as necessary for your local setup:
<ItemGroup>
<DB2License Include="C:\ProgramData\IBM\DB2\{FOLDER NAME THAT VARIES BY INSTALL}\license\**\*.*"/>
</ItemGroup>
<Target Name="CopyFiles" AfterTargets="AfterBuild">
<Copy SourceFiles="#(DB2License)" DestinationFolder="$(OutDir)\clidriver\license\" />
</Target>
The important part seems to be that $(OutDir)\clidriver\license\ has all files necessary to represent a valid DB2 11.1+ license before your application runs. For me there were 3 files. For server build and release, a slightly more complex setup may be necessary to get the correct files to the expected location.
Here are other things I tried that did not seem to help for me, but may help for others:
Some articles on IBM's site suggest adding %userprofile%\.nuget\packages\IBM.Data.DB2.Core\<version>\build\clidriver\bin or %userprofile%\.nuget\packages\IBM.Data.DB2.Core\<version>\build\clidriver\license to your PATH environment variable. This seems to be completely unnecessary.
Other articles or forum posts suggest copying your license files to the nuget package license folder %userprofile%\.nuget\packages\IBM.Data.DB2.Core\<version>\build\clidriver\license. This worked, but isn't ideal since it needs to be done on each machine after nuget package restore and then re-done if you change versions of the nuget package later on. And of course none of the places mentioning "hey just copy the license to this path" specified the default directory that contains your existing license: C:\ProgramData\IBM\DB2\{FOLDER NAME THAT VARIES BY INSTALL}\license\.
IBM DB2 Nuget package for .net core version 1.1 & 1.2 comes with DB2 Driver version 11. These two packages doesn't support if you have DB2 version less than 11. Here are the steps to resolve this issue.
Install IBM DB2 Nuget package version 1.0
Update your environment PATH variable with 1.0 installation path
Remove/Un-install any other DB2 driver installed on your machine
Close your Visual studio version and reopen it, it will work without any issue.
Also, 1.0 version doesn't require the license file. Hope this helps.
You can use this tutorial
https://www.ibm.com/support/knowledgecenter/SSFMBX/com.ibm.swg.im.dashdb.doc/connecting/connect_connecting__net_applications.html
/CODE EXAMPLE/
using System;
using IBM.Data.DB2;
namespace dotNetSSLTest
{
class Program
{
static void Main(string[] args)
{
DB2Command MyDB2Command = null;
// Use the dsn alias that you defined in db2dsdriver.cfg with the db2cli writecfg command in step 1.
String MyDb2ConnectionString = "database=alias;uid=userid;pwd=password;";
DB2Connection MyDb2Connection = new DB2Connection(MyDb2ConnectionString);
MyDb2Connection.Open();
MyDB2Command = MyDb2Connection.CreateCommand();
MyDB2Command.CommandText = "SELECT branch_code, city from GOSALES.BRANCH";
Console.WriteLine(MyDB2Command.CommandText);
DB2DataReader MyDb2DataReader = null;
MyDb2DataReader = MyDB2Command.ExecuteReader();
Console.WriteLine("BRANCH\tCITY");
Console.WriteLine("============================");
while (MyDb2DataReader.Read())
{
for (int i = 0; i <= 1; i++)
{
try
{
if (MyDb2DataReader.IsDBNull(i))
{
Console.Write("NULL");
}
else
{
Console.Write(MyDb2DataReader.GetString(i));
}
}
catch (Exception e)
{
Console.Write(e.ToString());
}
Console.Write("\t");
}
Console.WriteLine("");
}
MyDb2DataReader.Close();
MyDB2Command.Dispose();
MyDb2Connection.Close();
}
}
}

How to update AssemblyVersion using Update Assembly Info plugin in VSTS?

I want to update the version number of my .exe file using Update Assembly Info plugin.
I am using the following configuration:
But, I keep getting an error
'$(Date:yyyy.MM.dd)$(Rev:.r)' is not a valid parameter for attribute 'AssemblyVersion'
The $(Date:yyyy.MM.dd) and $(Rev:.r) can’t be used as the build-in variable, it can be used in Build number format (Options tab).
The workaround is that:
Include $(Rev:.r) in Build number format, such as $(date:yyyyMMdd)$(rev:.r)
Add PowerShell task to add a new variable (Arguments: -bn $(Build.BuildNumber)
Script:
param(
[string]$bn
)
$d=Get-Date -Format "yyyyMMdd"
$r=$bn.split("{.}")[-1]
Write-Host "##vso[task.setvariable variable=currentVersion]$d$r"
Then use currentVersion variable in subsequent tasks, such as Update Assembly task.

Powershell script in VSTS Build Definition not updating AssemblyVersion.cs

I have a Project hosted in VSTS and I'm experimenting with the Build Definitions. I'm trying to execute a powershell script that updates the AssemblyVersion.cs before the Project is built. When I run the script locally it works fine, but when it's ran during the Build process, the script runs without error, but the AssemblyVersion.cs is not updated.
$regex = '\[assembly: AssemblyVersion\("(.*)"\)\]'
$assemblyInfoPath = "..\Properties\AssemblyInfo.cs"
(Get-Content $assemblyInfoPath) | ForEach-Object {
if($_ -match $regex)
{
# Get current version, and update revision number
$version = [version]$matches[1]
$newVersion = "{0}.{1}.{2}.{3}" -f $version.Major, $version.Minor, $version.Build, ($version.Revision + 1)
'[assembly: AssemblyVersion("{0}")]' -f $newVersion
Write-Host "Version updated to: $newVersion"
}
else
{
$_
}
} | Set-Content $assemblyInfoPath
The Build output states that the version has been updated, but when I view AssemblyInfo.cs in the File Viewer it shows the old version.
The build process doesn't check in/commit changes made to source code automatically at the end of the process. You have to write a script to do that.
You need to checkin or push changes to remote repository.
If you are using TFVC, there is TFVC Build Tasks extension that includes TFVC-Check-in Changes step/task that can check in changes.
If you are using Git, you can add these steps/tasks to push changes:
Command Line (Tool: git; Arguments: add **\*.*; Working folder: $(build.sourcesdirectory))
Command Line (Tool: git; Arguments: commit -m "update"; Working folder: $(build.sourcesdirectory))
Command Line (Tool: git; Arguments: push origin HEAD:$(Build.SourceBranchName); Working folder: $(build.sourcesdirectory))
On the other hand, you also could build a custom build/release task and use it in your build/release. More information about custom build/release task, you can refer to: Add a build task
Note: It is not recommended to checkin/push changes to the remote repository in build or release.

Installing an exe with Powershell DSC Package resource gets return code 1619

I'm trying to use Powershell DSC's Package resource to install an exe... Perforce's P4V to be specific. Here's my code:
Configuration PerforceMachine
{
Node "SERVERNAME"
{
Package P4V
{
Ensure = "Present"
Name = "Perforce Visual Components"
Path = "\\nas\share\p4vinst64.exe"
ProductId = ''
Arguments = "/S /V/qn" # args for silent mode
LogPath = "$env:ProgramData\p4v_install.log"
}
}
}
When running this, this is the error Powershell gives me:
PowerShell provider MSFT_PackageResource failed to execute Set-TargetResource functionality with error message: The return code 1619 was not expected. Configuration is likely not
correct
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
+ PSComputerName : SERVERNAME
According to documentation, return code 1619 means the MSI package couldn't be opened. However, when I manually log in to the machine and run "\\nas\share\p4vinst64.exe /S /V/qn", the install works flawlessly.
Does anyone know why this is failing? Alternately, can anyone tell me how to troubleshoot this? I pasted all the error information I got from the terminal, my log file (p4v_install.log) is a 0 byte file, and there are no events in the event viewer. I don't know how to troubleshoot it any further!
EDIT: I should note that I also tried using the File resource to copy the file locally, and then install it from there. Sadly, that met with the same result.
Daniel over at the Powershell.org forums was able to figure this out for me.
The P4V InstallShield setup wrapper puts the MSI file into wrong path if you execute as LocalSystem.
I’ve managed to develop a Configuration that works, see below. The key is the /b switch here which puts the MSI file into a defined location. I’ve added ALLUSERS=1 to get the shortcuts visible to all users and REBOOT=ReallySuppress to avoid a sudden restart (which will happen otherwise).
Configuration PerforceMachine
{
Package P4V
{
Ensure = "Present"
Name = "Perforce Visual Components"
Path = "C:\My\p4vinst64.exe"
ProductId = ''
Arguments = '/b"C:\Windows\Temp\PerforceClient" /S /V"/qn ALLUSERS=1 REBOOT=ReallySuppress"' # args for silent mode
}
}
Well, what happens here is that the package gets installed (not tested with p4vinst64.exe yet! So, not sure why it says pack cannot be opened as the error) but since you did not specify a ProductID value, the verification at the end of install fails. That is the error you are seeing. The Package resource is no good for installing .exe packages or even MSIs with no ProductID represented as a GUID.
You can use the WindowsProcess resource instead.