Our automated build process is as follows:
The build script fetches the latest version of the repository into a clean directory
It runs the build using the following command line command
devenv SolutionFile.sln /rebuild "ServerDeployment|Any CPU" | out-file -FilePath $BuildOutputFile
I want this to run unattendend.
But then the build pauses to display a modal dialog:
An error occurred when applying the IIS Express settings to server URL 'http://localhost:60143/' for project 'CMS.Website'. You may have to manually edit the applicationHost.config file and make the changes for your site to run correctly.
I have to press OK for the build to continue. This is no longer a working unattended build.
I see that Visual Studio has automatically generated a file .vs\applicationhost.config in my build folder.
I compared this file with the file .vs\applicationhost.config in my development folder. I can see the version of the file in my development folder (which doesn't cause errors) has an extra site entry under the node: //configuration/system.applicationHost/sites
How can I make this message box go away? Obviously I don't care if this runs on IIS Express or not, because I'm performing a build to be deployed on a different server.
Possible solutions (that I don't particularly like) are:
Check the file .vs\applicationhost.config into the repository, so it gets checked out as part of the build rather than regenerated
Modify my build script so it copies the template file from C:\Program Files\IIS Express\config\templates\PersonalWebServer\applicationhost.config and then modifies this XML file to manually add the new site entry
Is there a better solution to my problem?
In my case, the debug settings were stored as part of the Web Application's .csproj file (which is part of the checked-in repository).
It should be stored as part of the .csproj.user file (which does not get checked in).
In my project settings I needed to make sure that 'Apply server settings to all users (store in project file)' was unchecked.
Once I unchecked this setting the automated build ran from start to finish without presenting a modal message box.
Related
Using Azure Build Pipelines i'm trying to publish an ASP.NET WebForms website to IIS.
Everything works, except that I have several images in a folder of my website (e.g. /Images/1.jpg,2.jpg, etc..) and I would like to delete all images from that folder except 2.jpg and rename it to 1.jpg after I've deployed the website (or during the release pipeline if that's possible)
Is there any way to do this in Azure Pipelines?
Here you can take a look at a Catalog of the built-in tasks for build-release.
The Delete Files task states:
"Use this task in a build or release pipeline to delete files or folders from the agent working directory".
This may give you some ideas on how to achieve this.
I hope this help.
Comment on:
The Delete Files task states: "Use this task in a build or release pipeline to delete files or folders from the agent working directory".
and
".. from what I just tried, this can only delete files inside the artifact and not on the IIS Server."
That is correct for default behavior, but it has a parameter called SourceFolder, which has a default as "$(Build.SourcesDirectory)". When you specify the SourceFolder to be "C:" you can enter a pattern to delete anything on the server. Might be wiser to use a bit more elaborate path then just c:\ but it works. Just tried it on a pipeline where a file needed to be deleted not from the workingfolder but from the deployed IIS location.
PS in a release pipeline the default seems to be the $(System.DefaultWorkingDirectory) and not the $(Build.SourcesDirectory). Whether that is because the Build.SourcesDirectory defaults to System.DefaultWorkingDirectory in release pipelines or the task is being smart I don't know.
I have a build definition set up on my TFS server. It builds happily but I can't figure out how to automate the process of having it copy the build to my development server.
I have a "Copy Files" task set up which works, but only when the source is this:
"C:\vsts-agent-win7-x64-2.103.1_work\8\s\ProjectName"
Obviously thats a hard-coded path and not great, so, is there an equivalent I could use to copy this build output to my development server?
Also, is there a way to have this happen over web deploy instead of file copy?
Thanks!
You can use the build variable $(Build.SourcesDirectory)\ProjectName, which should correspond to that folder. There is a link titled "Pre-defined variables" on the variables tab of your build definition that will show you other built-in variables.
I have converted a Win32 Application to UWP using MakeAppX and it doesn't seem to run. When I click the icon in the start menu literally nothing happens except a busy icon briefly appears on the cursor.
I completed the same process with Notepad++ and all it's DLLs and that worked fine (using the exact same manifest file, just changing the exe)
My questions are:
Where does the UWP save files that it creates/temporary files etc? If I run an executable and it generates files next to it, where would that be when you run a UWP?
Can I set that location in the AppxManifest?
Is there anyway to see if it has run correctly or not?
Edit:
Could this be a file permissions issue? My application needs to write to 'C:\MyFolder' & creates a folder with a load of files next to the executable upon startup and that doesn't happen.
So looking into this a bit more I came across this blog which discusses preparing for conversion. I think the above file accesses probably contravene the following:
Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
This looks like a fairly halting issue, am I correct in that assumption?
If your app is writing to the install directory you will need to change that code to write to your local app data folder instead, as the preparation guide calls out.
Write operations to the install directory are not allowed in order to ensure the ability for the app deployment stack to perform seamless, differential updates and clean uninstalls of your app.
Btw, to debug through your app launch failures you can do the following in Visual Studio: Debug -> Other Debug Target -> Debug Installed App Package -> select your app from the list of installed apps.
I have a production website that, once built in TFS is re-deployed and updated using xcopy. The entire site (excluding the root directory) it deleted then the new site copied in. This works well.
We use a 3rd party charting package that creates images at runtime and then renders a link to them. In order to do this it needs write permissions to a browsable folder.
Unfortunately, every time we update the website the write permissions of IIS_USRS is lost. Is there any way to retain this?
I guess it depends on what operating system the server is running, and whether you are building on the same server as you're deploying to, or a remote one.
The simplest thing to do is to put your xcopy command into a batch file, and include something like the following after the xcopy:
cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C
Or a more up to date option (I've not used this, so my parameters may be off):
icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M
Basically, either of those should give the user account that the site is running under modify (change) rights in the folder specified. This should be in addition to any existing rights on the folder, there are modifiers or switches to replace the existing rights.
If you are deploying to a remote server, you'll need some mechanism to run commands on there, we've found that PSExec works a treat (part of the PS tools from SysInternals).
I am using MSBuild to Publish a web site, then copy the published site to a web server on the same network. I set the copy command to "SkipUnchangedFiles."
It works swimmingly, but Skip Unchanged won't work because when I use AspNetCompiler to publish the website, each and every file is "new" -- its date is set to the moment of publishing, so even if the contents of a given file have not changed, the timestamp is different, so it's copied over anyway.
Is there a workaround that will prevent file whose contents have not changed from being copied?
Depending on how you're publishing the site, you may be able to do Incremental Build instead of a full build.
There is no existing process for this as the deployment process isn't aware of the deployment target filesystem.
If you were aware you could do a diff using a tool like beyond compare and then grab only the binary diff'ed items and copy those across.
Looking to automate this you are probably going to have to dig into writing msbuild targets or post build scripts.