MSBuild Pugin was not Displaying In Jenkins - msbuild

I am Preparing CI Setup So, I have Installed Jenkins in my Windows EC2 Instance But In Manage Jenkins--->Plugin Manager--->Available--> I am Searcing for MSBuild But it was not Displaying
Do i need Any Prerequisite For Installing MSBuild ??
enter image description here

Related

Wix MSI installer fail when changing build image in Azure Pipelines

As noted here a bunch of legacy images in Azure Pipelines are being removed in a few days. We have had some code using WIX building in Azure Pipelines for a few years now - using one of the images being deprecated (vs2015-win2012r2).
If I change my build image to e.g. vs2017-win2016, I get this error from my Azure Pipeline:
##[error]C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets(2439,7): Error
MSB4064: The "AllowDuplicateDirectoryIds" parameter is not supported by the "Light" task.
Verify the parameter exists on the task, and it is a settable public instance property.
UPDATE:
I can now also reproduce this locally. And I have found out that one of the changes from WIX 3.10x to 3.11x is this particular parameter:
AllowDuplicateDirectoryIds
I can also see that the Azure Pipeline image vs2017-win2016 has WIX3.11 whereas the Vs2015-Server2012R2 has WIX3.10 installed.
So everything fits ... my solution fails to build because it was targeted WIX 3.10 but the new image has WIX 3.11 installed.
So something inside my C# installer project still references Wix 3.10 and fails because the new 3.11 has some functionality that Wix 3.10 did not have.
What could that be?
As what you found, the wix version that vs2017-win2016 image used is 3.11. And also, unfortunately, we does not support to install customized wix version to override the one that located in Hosted agent until now.
In your scenario, you can consider to use one work around: set up private agent to build your project. Just ensure it is wix 3.10 exists in your local machine that private agent installed.
When build with this private agent, the system will detect corresponding tools from local system. So, it would be succeed if you ensure there has wix 3.10 located in the machine that private agent located.

Deploying a .Net application built in VSTS to a remote agent machine

I have been trying to figure this out for a few days to no avail.
I have an MVC .Net Application that is stored in a GIT repo in VSTS. When I check in code it is being built and unit testa are being run in the cloud.
Now If these unit tests succeed I would like the project to be deployed to a remote machine that has the VSTS agent installed. I can see the agent in the VSTS web interface but I don't know how I get the automatic build to send the completed build to d:/mydeploypath on the remote agent machine.
Is this possible?
Absolutely possible!
There are build steps available to copy files to a remote machine such as Copy Files over SSH and Windows Machine File Copy. But if you are trying to deploy the code to the machine you are building on, you can use the Copy Files step since it won't require credentials. Since it is a web application, there are a few steps like IIS Utilities to stop\start the application pool so the files won't be locked for the deployment.
So using the Copy Files build step, you could use $(Agent.BuildDirectory) as the source directory (or wherever you have your build output going) and set the target folder to your desired destination on the machine.
The build/release variables helped me out a lot during the development of our release process:
https://learn.microsoft.com/en-us/vsts/pipelines/build/variables?view=vsts
The easy way is using WinRM-IIS Web App Deployment task.
To generate the web deployment package, you can specify these arguments in MSBuild Arguments box of Visual Studio Build task:
/p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageLocation="$(build.artifactstagingdirectory)" /P:PackageTempRootDir=""

VSTS - publish a web application and copy files over SSH

I have a build process on VSTS which builds the web solution .sln file and publishes the artifact. All seems to be working fine.
Now I wish to use the artifact in a release to 'Publish' the web application and copy the published files over to a windows VM via SSH.
How can I get VSTS to 'publish' the application like it publishes in Visual Studio, or can I use the build Visual studio to publish.
.Net Framework Application.
Image - Build process in VSTS
If you must use SSH you can in your Release pipeline you can use the "Copy Files Over SSH" Task:
If you do not have to use SSH you can use the "Windows Machine File Copy" task:
These tasks will copy the build artifact to your windows VM.

ASP.NET 5 (vNext) Deployment via TFS 2015

We're trying to work through the new tool chain for building and deploying an ASP.NET 5 (vNext) CoreCLR web site to a server cluster. Between the new compilation changes and the changes to TFS, I'm not sure how everything now gets built and deployed. The scenario is as follows:
On-premise TFS for source control and build agent
Targeting ASP.NET 5 under CoreCLR, hosted via IIS
Questions are:
Using TFS for continuous integration builds (and hopefully deployment to an on-premise IIS server), how does one build and deploy this new application type?
It seems like MSBuild might still be usable to point at a .sln file so as to indirectly invoke dnu.exe, is that correct? Is that the appropriate way to do that now?
Should we be running a scripted build task instead to run dnu.exe instead?
How are these new CoreCLR builds deployed? Just a straight copy to a directory on a remote machine?
This is a new application and we're using a multi-layered application architecture, where the DAL and Business logic are in their own CoreCLR projects, if that makes a difference.
Thanks in advance for shedding some light on the situation.
Here is what we ended up doing:
Powershell script "prebuild.ps1" as per the previous answer and Microsoft deployment guidelines: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5
Vanilla MSBuild build. no switches or special settings.
Powershell script to execute xUnit test runner. We used guidance from this post at http://fluentbytes.com/running-xunit-test-with-asp-net-dnx-and-tfs-2015-build/
Powershell script to run "dnu publish". This creates a directory of the entire web application's structure.
"Windows File Copy" task to deploy the directory structure created in #4 to all of the target machines in the test environment.
To build and deploy ASP.NET 5 via TFS2015 vNext build system, you need to:
1). Create a PowerShell script (named Prebuild.ps1, for example) to install DNX. Details of the PowerShell script can be found: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5 . Add the script file into TFS version control.
2). Add the PowerShell script build step into build definition. Run the Prebuild.ps1 script in this step:
3). In the MSBuild step, specify the project needs to be built, and add the following /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MsDeployServiceUrl=localhost /p:DeployIisAppPath="Default Web Site/TFSTest1" /p:VisualStudioVersion=14.0 to publish the project to IIS.

Firebreath plugin installation available for all users

i have a problem with the installation of a Firebreath plugin on Windows XP machine.
I'm using Visual Studio 2008 setup project to place generated plugin dll in program folder to get the plugin work but when i run the installer the plugin is usable only by the user who install the plugin and if i log in the machine with another user with limited privileges Firefox cannot see the plugin.
What i'm doing wrong with this process?
Should i use Wix installer instead of Visual studio 2008 setup project to get the plugin work for all users in the machine ?
What is the correct "Firebreath" way to install a plugin and to make it visible to all users in the machine?
Thank for your time!
Francesco.
1) Nothing. This is as designed; FireBreath installs per-user by default, always has. This is a feature, since it means you don't have to have administrator privileges to install.
2) Not by default, no.
3) Uncomment the following line in your PluginConfig.cmake file and rerun the prep script:
# If you want to register per-machine on Windows, uncomment this line
set (FB_ATLREG_MACHINEWIDE 1)