So I have been banging my head against a wall on this one...I am trying to publish an Azure Web Role and I have two ServiceConfiguration files:
ServiceConfiguration.Cloud.cscfg
ServiceConfiguration.Local.cscfg
In my publish xml I have:
<AzureServiceConfiguration>Cloud</AzureServiceConfiguration>
So my assumption here is that when I publish it will use the Cloud cfg.
For working locally, under the emulator I have set the flag for local debugging to use Local.
However it would seem that this flag here also determines the cscfg to use for the cloud...so I am a little confused - is this the correct behavior or am I missing something? I really want to have a separate one for local as I have different values I need.
Update
Suddenly it started to work fine today. Didn't really change anything.
Tom, your publish XML configuration file is OK, and your publish to Azure will use the .Cloud.cscfg.
You can pick which of the configuration files you want to use when publishing (right click > Publish...), on the second screen (under Service configuration).
What you did for your local environment should work fine, and use the .Local.cscfg file.
Related
I have two projects I'm working on for two separate Web Apps on Microsoft Azure under the same subscription. The first Web App project works fine, but for some reason when I try to deploy my new project to the other Web App, VSCode keeps telling me:
Deploying [first-project-folder] instead of selected folder [current-project-folder]. Use "appService.deploySubpath" to change this behavior.
Even when I change this setting to point to the correct project folder, it does the same thing. Nothing changes. I'm using the Azure App Service extension in VSCode on Windows 10.
I had a similar problem, and it was because I was changing the deploySubpath in the wrong settings.json file. I changed the one in the directory I was trying to deploy and it didn't work.
Try changing settings.json under the root \.vscode.
We have set up Application Insights for our Dev & Prod environments, not with the SDK but through the Portal. We're now in the process of installing the SDK so we can have more control over customizing logging, what to measure in performance, etc.
I have found how to separate the environments in code (separate Instrumentation Key in different config files etc), but I have found nothing when it comes to my local environment. Which instrumentation key should I use there, the dev one? Wouldn't then this skew our dev metrics everytime one of the developers runs the app locally?
And also, doesn't it make sense to have a separate App Service slot just for the local environment, so I can test everything and see the logs I'm trying out locally, and not have to deploy to dev everytime I want to see what I'm doing?
I've tried creating a separate slot for local, but it generates a weird url based on the name I give, which I can't change later.
I've googled for a couple of days already and couldn't find any (or very little) helpful advice when it comes to this.
I realise there is a "Just add the SDK to try local only mode" option in Visual Studio, but then I would have to use it exclusively locally. What I want is to use all three - my local, dev & prod.
We're using .net core 2.2 for our backend and Angular 7 for front end.
I'm an idiot.
The url set up automatically basically means nothing. I solved the problem by just adding another App Service slot (created from our App Service production one, just like dev), and added this key to the local settings in our project.
Now we can use this key to get real time results as we debug, and use the other two for dev & production.
I have Created a cluster in Azure http://******.######.cloudapp.azure.com:19080
but don't know how to deploy my service fabric project on to it.
Link to application manifest
ApplicationManifest.xml
It's pretty well documented, unless you are getting specific errors, which you then will need to reference to get some worthwhile help
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-publish-app-remote-cluster
Your first option is to use the powershell commands. You can also right-click your application in visual studio and select "Publish". Make sure you are using the correct publish profile.
Within Visual Studio, navigate to your Publish Profiles folder under the application and copy/paste the existing cloud.xml file and then rename appropriately. Ensure that you use the correct public facing I.P for your cluster, which will most likely be the load balancer.
The line should look like the following.
<ClusterConnectionParameters ConnectionEndpoint="<YOUR IP>:19000" />
Example:
<ClusterConnectionParameters ConnectionEndpoint="151.41.35.35:19000" />
However, if the cluster is secured you may need additional information. These options are shown within the commented Cluster Connection Parameters of the cloud.xml file.
Right click on the application, select publish and ensure the new publish profile is selected. Visual studio will attempt to validate the connection. Try to publish and keep an eye on the output window for insight in to the process.
As far as I know, regarding web-roles, it is possible to have multiple ServiceConfiguration.cscfg files, one for each publish profile (for example, Cloud1, Cloud2, Cloud3, Local and so on).
Though, is it possible to have different diagnostics.wadcfg (wadcfgx) files?
How to instruct Visual Studio to use a specific diagnostics file when deploying to Azure? Is there a specific entry in the publish profile XML file?
Out of the box, it is not possible because there can be only one diagnostics.wadcfg (wadcfgx) file associated with a role in a cloud project a cloud project.
We are using SDK 2.4 in our project and the way we have worked around this problem is by creating separate cloud projects for each environment - Dev, Staging, and Production. Since these are separate cloud projects, we can have different diagnostics configurations.
If you're using SDK 2.5, one thing that works in your favor is the diagnostics is now an extension (instead of plugin). What that allows you to do is change/enable/disable diagnostics on the fly. Though I have not tried it but one thing you could possibly do is enable diagnostics as a part of your deployment process. By default there won't be any diagnostics.wadcfgx file in your project. When you deploy your code via PowerShell, after successful deployment, you can enable this extension. Please see Step 4 here: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/#worker-role. (Since I have not tried it myself, I would be very much interested in knowing the outcome. Please do share if this approach worked for you).
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.