I've added a handful of new builds to a long standing CruiseControl.Net setup. Everything has been smooth up until this point. Now, any changes I make to the header.xsl file do not display on the build results dashboard page. This behavior only appeared after the weekend, and I'm not seeing any errors from CC.Net. Any clue as to what might be causing this? I've already attempted restarting both CC.Net and IIS.
Current CC.Net version info: 1.5.7256.1
When changing something related to dashboard configuration (or XSL files) you should
restart web server
restart ccnet
From my experience
using ccnet as service + apache + mod_asp, I need to restart only ccnet service.
using ccnet as service + IIS, I need to restart IIS and sometimes to restart the PC !
Did you change the correct header.xsl?
For the web dashboard you want to change webdashboard\xsl\header.xsl, and may need to reload the dashboard config before you see the change.
The server\xsl\header.xsl file is used when using the EmailPublisher.
Related
I am new to Azure and I have created a very simple App Service in Azure with everything default. Changed the App Service Plan to B1. I can browse the app service home page and see the default page. I then connect using FTP and try to change the default page, but it did not reflect changes.
I even downloaded publish profile and published a .net core 3.1 web api with defaults, I can see the files are deployed using FTP but the api is not present. I even deleted the default page but the home page still appears. It seems the ftp is not pointing to default location where files are being picked up by asp.net core.
You can refer my answer in this post. Then use kudu to check whether the time of the last update file via FTP is consistent with the release time. If the file is not updated, of course this update has no effect. Then we can check the FTP connection str.
But first, I suggest you to modify index.html or default interface function and update by kudu. Then check if the update file is effective. If success, I can sure you code is ok.
Second, check your FTP Connection str.
Step 1. Find Deployment Center->FTP, click FTP then you can see Dashboard, into Dashboard find FTPS Endpoint,Username and Password.
Step 2. Use FileZilla, connect it. You can see files in it.
Then you can try again. Under normal circumstances, there is no problem to update via FTP.If the problem is still not resolved, I suggest that you can deploy to local IIS for debugging.
I was facing same problem like, publish contain not displaying when visit website. then i change following settings and it worked.
I had the same issue updating files in FTP and the dlls weren't being updated as they were being used by the site. I had to stop the App Service first and then update the files. The changes then reflected when restarting it.
We are running several WebForms-Application on a Web Hoster (classic IIS, no Azure, no Docker, etc). For some months now, ca. once a month, one or more of these (virtual) applications stop working all of a sudden. In the Application Log Files there is an HttpException: "The file ....aspx was not precompiled and could not be requested." After redeploying (republishing) the application everything is working fine until next month. The Hoster did not find anything inside his log files.
What could be the problem? Where to start search?
Make sure that you used Release Mode, it is always recommended that you publish website in Release Mode
Publishing package in my local system is taking much longer time than expected. It is taking around 15-20 minutes to publish, and sometimes it is throwing an error, UNABLE TO READ DATA like this.
I also tried even after Restart Application from Apply Updates screen but still same issue. How I can solve this?
You might want to try to disable web site building.
In Visual Studio, go to web site property pages and deactivate the following 2 configurations:
Uncheck Build Web site as part of the solution
Before run startup page - no build.
See http://asiablog.acumatica.com/2016/09/make-compilation-of-extension-library.html
So I imagine this is a pretty simple problem, but I can't find anything about it.
I've set up CruiseControl.Net to check my svn repository for any changes every 30 seconds, and if there are any changes, build them using NAnt.
Everything works great - but only if I have the CruiseControl.Net console running at all time on the server. If I close the console, it won't check for changes and build them. I've checked the wiki for a way to set up continuous monitoring, but I can't find anything
Does the console always need to be running in order to detect changes, or is there another way to do this?
There are two ways to run CCNET: As console application or as windows service. You're looking for windows service mode.
Here is a tutorial on "Installing CCService". Be aware that this documentation is outdated. But it should give you an impression.
Installing CCNET as a windows service is an option during CCNET installation so this is the easiest way to get it up and running.
I've got a TFS build set up to build and deploy a web application. I'm passing in the MSDeploy parameters via the TFS build definition's MSBuild arguments. First time round this is working fine. When someone accesses the web app, one of the controls (Microsoft charting control) generates a couple of files in an empty directory I've added to the solution.
When I go to rebuild (or continuous integration is triggered) the next build will usually fail because it can't delete one of the generated files. When I try and manually delete the file it tells me that IIS worker process is using it and it can't be deleted.
Now to get the build building I'd have to manually restart IIS every time, which is not desirable with CI in mind. I've taken a look through Microsoft.Web.Publishing.Tasks.dll and there's nothing there to restart IIS using MSDeploy.
At the moment I'm thinking that adding stubs of the temporary files in the solution might be a resolution (maybe MSDeploy will be able to close the process if the file is a permanent part of the deployment) or I could do some unpleasantness with Exec in the solution file to get an IIS reset.
It's probably a long shot but has anyone come up against this and found a nice solution?
You could use MSBuild Extension Pack to stop the application pool automatically before deployment. There are several tasks in the MSBuild.ExtensionPack.Web namespace to manage IIS, such as stopping and starting an application pool, deleting an application, etc.