I am using CruiseControl.Net for continuous integration. I use the CCNetLabel to version the assemblies that are built.
However, if the service is restarted for any reason, the CCNetLabel starts again at 1.
I am using the defaultLabeller. Is this the expected behaviour? can this be changed?
That's certainly not the expected beviour. I suspect that there could be a problem with saving the state file for the project. By default it is saved in the directory the service was launched from.
Make sure the account the service is running under has write permissions in that folder or change the location of the state file (recommended) in ccnet.config with the state element.
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.
ASP.NET Core 2.1
We have a shared dll, that is used in a few projects (via project reference)
We have class in that was named Proofer, and is now named ProofReader.
This was done through mass find and replace.
Nowhere in our source files locally exists any files containing the text Proofer.
VSTS builds the application without issue, then we send it via a release pipeline to Azure. All succeed.
Despite this we attempt to run the web app and get the following:
An unhandled exception occurred while processing the request.
TypeLoadException: Could not load type
'MainShared.Models.Proofer' from assembly 'MainShared,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule
pModule, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob,
Int32* pcNamedArgs)
We are having trouble determining if this is in the build, maybe something not being rebuilt when it should be, or something still cached on Azure that isn't being overwritten.
A few places I can suggest you look into -
If you are using app service web apps in azure , we can use the kudu (web app extension to remove/clean the files) to make sure you have a clean destination.
Check the VSTS Release logs if you have access to , it shows the files which are overwritten and the ones which could not be. Once i had a similar issue and found that the logs were already warning me that a few could not be overwritten.
If you are using VM's for your app deployment if has access to it , remove/backup the files under your site folder.
I had a similar problem after some redesign for a Web App using ASP.NET Core 2.2 (hosted on Azure), that some old not even anymore existing references causing the Load type exceptions to happen and the Web App simply refused to come up. I tried to clean everything up in Visual Studio, even deleted the bin and object directories, but the old reference was still looked for. In Kudu on the Azure portal I saw the *.PrecompiledViews.dll and *.PrecompiledViews.pdb files, which were very old. I simply removed them directly on the Azure server and could then simply start up my app and everything came up again. This fault should be fixed from the source. If I do a complete rebuild, I expect this old garbage to be taken care of during the publishing to the website. This is something that Microsoft should fix and as I can see this happened to others over half a year ago. Thanks Mark Johnson for your very useful hint about those files!
I need to replace one dll-file in deployed azure worker role to one that I modified, because role contains a bug and I don't have a release tag. I'm trying to do that via rdp, but when I'm trying to copy new dll into approot folder VM tells me that old dll file is open in another program and can't be replayced.
This isn't a good idea. You should do this by repackaging the deployment and performing an update. By attempting to do this via RDP you may replace the file, but if the role goes down or gets moved then when Windows Azure bring the role back up the change will be gone since it will redeploy the last package it knew about, so you'd be back to the dll with the bug in it.
As for why it is telling you it is open is because the worker role is actively using it most likely. You'd have to stop the worker role process to be able to replace it. The best option is still to perform an update of the whole package.
You can see this documentation for more information about how the updates occur: http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx
I agree with MikeWo's suggestion about repackaging and updating the deployment.
However, if you want to drop the single DLL and check to see if fix works. you can kill WaWorkerHost.exe - the blue highlighted process in the picture. then you can replace the DLL.
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.
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.