Is there a way to have MSBuild create an instance of IIS on another remote machine?
I do the builds (which occur locally using TeamCity AFAIK), but would like the code to be pushed up to our testing server once the build is completed. I am using IIS 6.x (Windows XP dev and Windows 2k3 Server for testing).
Did you check out MsBuild Extension Pack? It has a task called MSBuild.ExtensionPack.Web.Iis6Website wihch can be used to create a web site.
Disclaimer: I have never actually used that task with remote support, but the documentation claims is it supported :)
EDIT: you could also have a look at the WebDirectoryCreate task in the MSBuild Community Tasks project.
Another option is to use MSDeploy (which you can call from MSBuild). With MSDeploy you can install a Remote Agent Service which listens for actions to be executed on the target IIS server.
Related
Where can I see the system capabilities of hosted agents? I went here and it only shows user capabilities:
https://dev.azure.com/{myOrg}/{myProj}/_settings/agentqueues?agentId=8&queueId=91&view=capabilities
Trying to find versions of msbuild and paths to it on the computer. I need to use version 16
You can check the tools and softwares installed on the Microsoft hosted agent here. Click the Link shown as below screenshot to see the included softwares.
Unfortunately msbuild seems not installed separately, as it cannot be found in above hosted agents. But you can directly use Msbuild task and specify the msbuildVersion to 16.0 in your pipeline. The pipeline will automatically download the specified version msbuild from the cloud.
And also you can build your own self-hosted agent to run your pipeline. and manually download msbuild version 16 to your on-premise machine. So that you can specify the msbuild location in msbuild task to your on-premise msbuild location.
They have actually open sourced the Hosted Agents and you can find out all the information required from the repositories:
https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/pipelines/agents/hosted.md
The have links for each of the Images that are available at this link:
https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/pipelines/agents/hosted.md#software
Windows2019-Agent
https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md
You can also add Demands to Agents:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml
This can be used to ensure the agent has your the specific software needed for your builds.
so after .net core 1.0 got published I started a new console project and imported the code from a small prototype that is supposed to run without IIS. Besides having to use net46 in my project.json due the not-yet updated MongoDB.Driver, that worked fine. When I build the app in Visual Studio a small App.exe with a lot of dll is build and can be run fine locally without IIS.
I then noticed the option to build for IIS Express and thought that I can use the IIS on our server (IIS 6.2, Windows Server 2012 R2) too. It publishes fine with WebDeploy, but nothing happens after that. I was following this official guide. I installed the .NET core Windows Server Hosting bundle and everything appears to be in order, but when I browse to the url, I get a ERR_NAME_NOT_RESOLVED. Theapp.exedoes not appear in the Task Manager and I can't find any log file, although it is enabled in theweb.config. I can execute the app manually, but then it only listens on the defaultlocalhost:5000` address.
If I understood it correctly, the IIS is supposed to act as a reverse-proxy to the dotnet tool which starts a dll, but in my case it's already a compiled exe that works standalone. But I can't figure out how to build a dll from this app..
What am I doing wrong?
If you target full .NET Framework the application will be .exe and not .dll and it is fine. ERR_NAME_NOT_RESOLVED indicates that the url you provided in your browser could not be resolved and the request to the application was not made. AspNet Core Module starts the application on the first request and because the host could not be resolved the request was not made and the application was not started. Once you figure out why the name could not be resolved and you still have issues with making your application work with IIS take a look at my post which explains how things work and how to troubleshoot issues. This, however, only applies after the request can reach your application.
am trying to evaluate ccnet, I have gone through a number of tutorials/blogs which describe in detail on how to install ccnet. However most of them assume that CruiseControl.NET is being installed on the same machine on which Subversion repository is or it is a server machine.
I would like to know if ccnet can be installed on a non server machine and pre - configured subversion?
Sure this is not a requirement to install CCNet on a Server nor on the same machine as your repository.
CCNet can run as console application or windows service and both can run on windows, windows server and linux/mac with Mono.
Thus CCNet uses the native applications for source control operations (e.g. svn.exe or git.exe) it also supports the same remote repository features as its source control application. So your Subversion repository can be located everywhere your CCNet machine has access to.
I recommend you to read the Scenarios Section in our wiki.
I would never install my CC.NET on the same machine as my SVN repository. But that is me.
For local testing, you can run the command line version, and not the service. It's helpful, because the Console output actually let's you pick up on a few things while it is running. (Nothing you can't find with the service, but its cool to see it "in progress").
When you do install CC.NET, I would install it on a "clean" machine. The way I like to use CC.NET is to think of it as a "big fancy msbuild wrapper".
Your CC.NET will pull code from the repository, and I like to pull the .msbuild defintion file from svn as well (meaning, you store it there), and then have cc.net use the "msbuild.exe" task. The less custom cc.net tasks you use, the better. If you put 99% of your build logic into a .msbuild file, you'll won't screw yourself if you ever leave CC.NET for TFS.
3.
Yes, it has to be able to "talk to" SVN under some Identity. This identity needs read (maybe write) rights back to SVN. But it is the identity (account) that pulls the code from SVN. If your source code is projected (most likely it will be), then you may have to do some command calls using svn.exe to "accept the (p)ermanent certificate, using the IDENTITY that runs the CC.NET service.
You'll probably have some dependencies you'll need to install. I would NOT install Visual Studio 200x or 20xx. Download and install SDK's and other things as needed. Keep the build machine "clean". Document what you install.
It is a good practices to have CC.NET running in the same environment as developer(s).
So having a standard Win7x64 OS for CC.NET is nice to reflect the dev environment.
CC.NET can be configured to access a remote or local Subversion repository depending on the svn configuration you setup.
So the answer is : yes !
I'm trying to deploy a two-websites project in a Visual Studio 2012 solution via TFS as part of a build. We're at the point where we have two different web servers, WIP (work in progress) and DEV.
We want to deploy different connection strings to either server so they can connect to different databases. We've tested our solution on a development machine with Visual Studio and for all configurations, when any web project is published, the web.config connection string is transformed as expected when we check the web server.
The build is working fine on the WIP server which uses the default Debug solution configuration. The configuration in the TFS Build is Any CPU|Debug.
For the next configuration (DEV), we are sure that the web projects both publish via Visual Studio 2012 to the web servers and that the web.config files transform.
However, when we run the DEV build using MSBuild arguments, we notice that no transformation happens. We've sent the configuration in the Items to Build section of the build to: Any CPU|Dev.
/p:VisualStudioVersion=10.0 /p:DeployOnBuild=True;PublishProfile=app.ui.dev.pubxml /p:DeployTarget=MsDeployPublish /p:MsDeployServiceUrl=https://server-dev-hrtech:8172/MSDeploy.axd /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=WMSVC /p:AllowUntrustedCertificate=True /p:Username=username /p:Password=password /p:_WPPCopyWebApplication=True /p:PipelineDependsOnBuild=False
When we look at the build log and output directories - we can see compiled assemblies in the obj/Debug directory and not the obj/Dev directory as we'd expected. In the logs, we can clearly see /p:Configuration="Dev" as we'd expect.
The bottom line is the published web.config that ends up on the web server is the default web.config file from the Debug configuration (that is, untransformed). It is as if MSBuild is unable to see the configuration parameter passed in the arguments for the solution.
I've now tried running msbuild from the command line on my development machine to try and understand why this would happen.
By stripping back the MSBuild parameters that are sent via the TFS build, I can see that this doesn't transform the web config:
msbuild "app-no database.sln" /t:app_ui:Rebuild /P:TransformConfigFiles=true /p:Configuration=Dev /p:Platform="Any CPU" /p:MSDeployServiceUrl=https://app-dev-hrtech:8172/MSDeploy.axd /p:Username=username /p:Password=password /p:DeployOnBuild=True /p:PublishProfile=app.ui.dev.pubxml /p:VisualStudioVersion=11.0 > build.log
I can modify this and use MSBuild to build the project file directly. I've discovered that the command below does transform the web.config file for the published application:
msbuild app.ui\app.ui.csproj /p:Configuration=Dev /p:MSDeployServiceUrl=https://app-dev-hrtech:8172/MSDeploy.axd /p:Username=username /p:Password=password /p:DeployOnBuild=True /p:PublishProfile=app.ui.dev.pubxml /p:VisualStudioVersion=11.0 /p:AllowUntrustedCertificate=True > build.log
The problem is this would be difficult to run as part of a TFS build where they are multiple projects which some for websites and others for Windows servers, etc.
How can I use the first command, but amend it so that it properly transforms the web project?
As you can see I've created some publish profiles, so potentially they can be used in the MSBuild arguments as well in the TFS Build.
PS: we're using Visual Studio 2012, TFS 2010, Windows 2008R2 for servers and Windows 7 for development machines.
I've encountered this problem, regarding how to publish a web site through Publish Profile file, this article is the best one I ever saw.
For you case, it seems that you need to make the profile name same as the configuration name, e.g. use Dev.pubxml and Web.Dev.config.
/p:DeployOnBuild=True;PublishProfile=app.ui.dev.pubxml
I dont think that .pubxml should be at the end of the profile.
Should be like this
/p:DeployOnBuild=True;PublishProfile=app.ui.dev
It looks like TFS 2010 Build doesn't call the Transform MSBuild task by default. You need to edit either your TFS build defintion to add a new activity which calls it or edit your project file to do this.
Stack Overflow question TFS Build not transforming web.config as expected should help you with adding the new acitivty and blog post Integrating Web Config Transformations with TFS Build for making changes to the project file.
I just had this problem. Checked the MSBuild logs, checked making a local ZIP package, checked Web Deploy push to remote IIS and it was always using the default config file!
Turned out that the lump of XML I was looking at to check for my QA settings was lacking the xdt:Transform="Replace" attribute!
Hope this helps someone.
Our team is going to be developing against SharePoint using local VMs. Our VMs are not allowed to join the host domain. Additionally our host nics are prohibited from using Internet Connection Sharing. We have a requirement to source control all our development work using Team Foundation Server. Our TFS installation is using Kerebos for authentication.
To be able to use TFS for source control we were thinking we could share a folder between the host and VM, do our work on the VM, save to the shared folder and then do check ins and such from the host which will be able to authenticate against TFS.
I'm hoping there is a cleaner way to do this or someone with similar restrictions can provide some insight.
Note: I have successfully setup a similar mechanism using Tortoise SVN and Ankh SVN that works, but management will not budge on the TFS requirement. Not that I blame them either, the license is very expensive and they want to feel they are getting their money's worth. Therefore TFS has to be included in the answer.
Here's a solution that works perfectly for SharePoint 2007 development.
We run virtualised instances of Windows Server 2008 on our Windows XP machines at the project i'm on. We use Sun VirtualBox as the virtualisation software.
secondly, each VM is a standalone domain controller + sql server + reporting server + analysis server + sharepoint server and as such isn't joined to the main domain.
when opening up Visual Studio 2008 and connecting to TFS you don't need the machine/server to be connected to the domain as the VM NATs through the host machines network adapters - use a fully qualified address for your TFS and you shouldn't have any problems connecting to TFS from within the VM.
you may need to turn off integrated windows authentication (IE -> Tools -> Internet Options -> Advanced)...
We also run VS08 in the VM and not on the host..
Another thing is to use WSPBuilder to build your solutions and create the deployment scripts for you (or alternatively just set up an external tool/command from VS08 that runs the stsadm.exe -o deploysolution command)..you can deploy effortlessly to the VM and ensure that it runs fine - then just check in your code, set up build scripts that fires off WSPBuilder on the build server to build the solutions for you and deploy from there (or copy the WSP up to the server and run them there).
I think your solutions is as clean as it will get.. you could map a folder on your host machine and open the Visual Studio project straight from there within the VM. Saves copying. Committing will have to be from the host. Use of TFS features will be a bit awkward, you'll have to open VS on your host machine as well to connect commits to work items etc. Not exactly what the investment in TFS was for.
How come they've dished out the cash for TFS but are not willing to facilitate it? The VM's should really be in the domain.. or at least a trusted domain.
We run the same setup except we do have SVN and can commit directly from the VM. Workable :)
BTW, if you develop for SharePoint 2010 this gets better; it'll allow installation on non-server OS's so you can develop on your local machine (which I guess, is on the domain).
I generally use VS2008 running on the host with the SharePoint assemblies installed to the GAC of the host. I use build events/build targets with a shared folder and sysinternals to build directly to the SharePoint VM's bin/GAC folders. This way Visual Studio builds directly to the SharePoint server and you do not have to manage 2 installations (host and VM). I would also recommend installing VS2008 debugger as a service on the VM for easy debugging.
Hope this helps!