I created a project for crossplatfor C++ ( visual studio )
I created 3 projects
Proj.Lib.Linux
Proj.Lib.Windows
Proj.Lib.Shared
on the configuration of the Proj.Lib.Linux i defined
platform toolset to be => 'Clang for Windows Subsystem for Linux'
WSL distro name to be => 'Use the default WSL distribution on this machine'
and all work ok - I can debug and run in with no problem.
Now, I want to build this lib for Linux and Windows for production (using Jenkins).
But on the machine that contains the Jenkins I don't have WSL -
I don't know how it's possible to build it now.
How I supposed to add a pointer from the Jenkins to wsl for the platform toolset or to the wsl for building it?
Related
I have a release pipeline in TFS 2017, which runs on Linux agent and has Docker and PowerShell tasks. However Docker tasks are working fine but PowerShell tasks are failing because there is no .Net Framework installed.
What is the way to run PowerShell task on Linux agent or how to install .Net Framework on Linux agent?
TFS 2017 predates support for PowerShell Core, which is cross-platform and runs on Linux. So the built-in PowerShell task is going to be useless for this scenario.
However, you can still run a PowerShell script on your Linux agent, you'll just have to use a Command Line task to call pwsh. Naturally, you'll have to ensure that PowerShell Core is installed on your Linux agent.
Upgrading to a more recent version of TFS will also include an updated PowerShell task that includes a checkbox for "Use PowerShell Core", which will also solve the problem.
I am using TFS 2017 and recently added RHEL Linux build agent with docker installed on it, but when I am trying to queue docker based build on this agent I am getting below error
Issues with deploy phase 'Run on agent' - No agents could be found that match the following demands (queue: 'DockerLinuxRHEL'): DotNetFramework
I have also tried removing it from build definition, but it's greyed out.
Is there a way to remove this default demand because this agent is just for docker stuff I don't want to install anything else?
It because you have a task that required .Net framework installed, like PowerShell, MSBuild, etc.
When you will remove the task the demand will be removed.
How to remove default demand DotNetFramework from TFS agent?
I am afraid we could not remove the default demand DotNetFramework.
Just like Shayki said the demand comes from the powershell task itself. So, if we want use the powershell task, we have to install the Net Framework on Linux machine.
However, it's not recommended to build .net framework projects in Linux environment. Usually we use mono with reference assemblies and the dotnet cli to do that.
More details please refer to this blog and the discussion here.
So, remove default demand DotNetFramework or install Net Framework on Linux machine is not a viable option.
To resolve this issue, we could use the PowerShell Core task:
- pwsh: # inline script
workingDirectory: #
displayName: #
failOnStderr: #
errorActionPreference: #
ignoreLASTEXITCODE: #
env: # mapping of environment variables to add
Note: pwsh runs PowerShell Core, which must be installed on the agent or container.
Hope this helps.
There are many similar questions like this, but my scenario is slightly different.
I use Visual Studio Enterprise 2017, dotnet Core app 2.0, on a Windows 10 Pro machine, where is running docker for windows.
I can run and debug my applications in my local machine's docker server, but now I would like to configure visual studio, for my current project only, to run the application in another docker server.
So in practice instead of running commands such as docker run, docker build and so on, I would like it to use docker --tls -H={theotherdockerserver} build ...
I could not find so far any parameter or configuration section that allows me to do so.
You need to have all your files accessible from remote server. One way to do this is to put your code in GitHub repository and run command: docker --tls -H={dockerserver} build https://github.com/{user}/{repository}.git
Documentation for GitHub build.
Do you need an option without GitHub repository?
I'd like to set up a Hudson slave agent (v3.2.2) as a Windows service on one of my Windows nodes (running Windows 8.1 x64 with .NET 3.5 installed). As of this wiki page, there should be a File > Install as Windows Service menu option. But when I run the JNLP, there's no such option:
So: How do I install the Hudson slave agent as a Windows service?
There is a bug that has been submitted for this, Bug 427526, and also a workaround. It is related to the version of Java. I used JDK 7u11 and I got the File option and was able to install the slave as a service.
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.