As of Wednesday, sometime between 2:01 pm and 2:43 pm Eastern, Visual Studio Team Service Release Management began failing in the Azure Web App Deployment Task, during the Deploy Website to Azure step with the generic error:
You cannot call a method on a null-valued expression
We created a new Release Definition, but it exhibits the same issue.
I attempted a Release with the previously successful version of the build, and it too exhibits the same exception.
I have verified that there is no deploy.cmd in the repository.
I have verified the items in the change set for the build.
They only touched one .cs file, three .js files, and changed the value of the <add key="Client.CacheVersion" value="X"> from 4 to 6.
Though the documentation states that the -ErrorVariable is valid for the script in question. The only difference in the log files (pre-failure information) is the addition of -ErrorVariable publishAzureWebSiteError to the end of the Publish-AzureWebsiteProject call.
Is there anyway to either populate the publishAzureWebSiteError, or remove this extraneous variable?
UPDATE:
After adding system.debug. I see that I am unable to resolve {mysite}.scm.azurewebsites.net.
UPDATE II
After 2 hours with Microsoft it appears that Release Management is having some difficulty working with App Service Environments. At first it was unable to map the scm URL appropriately and once we added the expected suffix to the Web App Name field we received the error:
Conflict: The host name MY_WEB_APP.APP_SERVICE_NAME.p.azurewebsites.net is already assigned to another Azure website: MY_WEB_APP.
FINAL UPDATE
It appears that the releases are now running as expected with in at least on the previously failing releases no changes were made. Since MS clearly changed something on their end, this question will provide no benefit to future users. I am voting to close it.
As this question has yet to be closed.
For those that come after:
The fix came from Microsoft. Premier support emailed me with the following this morning:
I just spoke to the developer who pushed the fix. And the fix has to do with correctly forming a SCM name which in your case is part of ASE. So there were no exceptions being raised this time and it worked for you.
So there are/were no workarounds, nor changes even possible on the part of the end user.
Related
Hey I have deployed new azure function using Azure dev ops CI/CD. The function app has been deployed successfully and when I go to the main URL, it says your function app is running. I tried to test the end points("/save") using azure portal and the output is 404 Not found. The same results when I use POST man as well. Any help would be appreciated?
2020-11-21T11:30:45.769 [Error] The following 2 functions are in error:
Get: The function type name 'DocumentContextFunction.Functions.GetDocument'
is invalid.
Save: The function type name
'DocumentContextFunction.Functions.SaveDocument' is invalid.
I have fixed this by updating the value of the "FUNCTIONS_EXTENSION_VERSION" from 1 to 3. For some reason every time I deployed using Azure CI/CD, its value is set to 1, so I have to manually change it to be 3.
I encountered this error when my build targeted win-x64 whereas the Azure Function Platform was configured as 32 bit.
In my case I had a function created in portal. I then published a function via visual studio. After publishing the portal created function was 404 not found and I could not even delete the function from the portal.
Exact same code in a new function worked as expected.
This is not intuitive and were no indications in the portal that previous portal created functions would break.
This maybe buried somewhere in documentation but I would have expected a warning in azure before allowing other functions to break without code changes.
The author's question helped me understand where the problem was coming from. In my case, it was not about the CI/CD pipeline doing anything funny.
It was my IaC code which was not setting up the function app properly. It picks version ~1 by default but I had to set it to ~3.
My function apps were working until I included a new custom package with a later version of Microsoft.Extensions.Logging. My functions were using Microsoft.Extensions.Logging 2.1.1. The package had version 7.0.0, which is for Net7. It was incompatible with my Net6 projects.
When the package was added, the Microsoft.Extensions.Logging version in my project was updated to 7.0.0. The were no compile errors, but debugging showed that the assembly could not be loaded. This was causing the 404.
Changing the package version back to 2.1.1 corrected the problem.
This is what worked for me...
Note: I was getting 404 on my function which is a nodejs and inline editing on the browser.
Open your function.json and take a backup as we are going to change it.
See if in your function.json there are two different settings with "direction": "in"
For me there were two. I tried deleting but it keep coming back.
Next I went to 'Integrations' (on left menu) and opened my trigger and deleted it. This will recycle your trigger. And hope this works for you too.
I designed a CI/CD pipeline to deploy an ARM Template from github to create an instance of api management in my resource group using the ARM Template.
In my release logs, I am constantly getting this warning "Can\'t find loc string for key: CorrelationIdForARM" which is slowing down the process. Although after taking a long time the resource is successfully created still the release appears as failed.
logs
There appears to have been some change introduced by Microsoft that started prompting these warnings when using App Service-related steps. In my case, we use separate steps to first stop, deploy, then start an App Service, and each one of those steps contains at least five of these "warnings." We don't do anything advanced either, just simple deployments; no slot swaps, no ARM templates, just .NET Core code deployment.
Microsoft appears to have heard our complaints and already reported "we have merged the fix for the issue." Not sure how long until we will see that fix implemented however, as it appears to be more of an annoyance rather than something that breaks builds.
https://developercommunity.visualstudio.com/content/problem/859513/azure-app-service-manage-warnings.html
They just announced the solution for this is being deployed and should be fixed for all accounts by the end of the week:
Hi, the fix for CorrelationIdForARM warning is already merged and is under deployment. It should reach all the accounts by the end of this week. Thankyou for your patience.
Source: https://github.com/microsoft/azure-pipelines-tasks/issues/11996
still getting this error, its getting worse now. Agent Jobs just hanging now.
"Can\'t find loc string for key: CorrelationIdForARM"
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 created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.
I just created a Windows Azure account. When I try to deploy from VS2010 I get the following messages that just keep repeating on and on:
2:17:43 PM - Warning: All role instances have stopped
2:18:23 PM - Instance 0 of role MvcApplication1 is busy
2:18:59 PM - Instance 0 of role MvcApplication1 is stopped
2:18:59 PM - Warning: Instance 0 of role MvcApplication1 appears to be cycling and unable to start.
2:32:44 PM - Warning: All role instances have stopped
2:33:17 PM - Warning: All role instances have stopped
2:33:49 PM - Instance 0 of role MvcApplication1 is busy
Does anyone know how I can debug or find out what's wrong? I don't know what to do at this point.
I ran into this problem myself. Mine had to do with not having the assemblies packaged in my service when publishing. Use the following steps to resolve this:
1-Get all of the Deployable Dependencies into your project
Use the "Add Deployable Dependencies" feature from VS2010 SP1 and alluded to here in Scott Hanselman's blog post about BIN Deploying (see "Interesting Note" at the bottom of the post).
Essentially, right click on your project and you'll see it within the "Add" section. A dialog box will pop up with 3 choices (in my case 2 were accessible). After selecting them, a new folder will be added to your project called "_bin_deployableAssemblies" which will contain any assemblies your project needs to run in the cloud which the References you have are dependent upon.
If you don't have VS2010 SP1, then go ahead and follow the advice in Scott's blog post (which essentially does what the feature does, just you're doing it).
2-Check your References for Copy Local = true
Once you've done this, if you still have problems, start checking your reference assemblies for any References you have which are not expected in the cloud OS you are targeting, and make sure to set Copy Local = true.
3-Check your References for the Windows Azure assemblies
Because I created my Web Project first, I had to manually add the Windows Azure assemblies to my Web Project that was the target of the Web Role. (Microsoft.WindowsAzure.Diagnostics, Microsoft.WindowsAzure.ServiceRuntime, Microsoft.WindowsAzure.StorageClient)
4-If you're using MVC 3, use the workaround
Take David Makogon's advice and follow the steps on Steve Marx' blog post.
Debugging Azure apps which get stuck in this loop is hard.
The cause is normally that your role simply won't start because of a build problem.
In this particular case, I'd guess that maybe you haven't included one or more of the MVC assemblies inside your package - check that the MVC references are marked with Copy Local - e.g. see http://msdn.microsoft.com/en-us/library/dd410407.aspx (and other links depending on which MVC release you are using!)
If your MVC application is MVC3, the newest MVC libraries are not installed in the Windows Azure guest OS image yet. See Steve Marx' blog post for two easy ways to install the MVC3 libraries.