How can I locally test the RoleEnvironment.Changing event using the Azure SDK 1.7? Which file do I have to change and do I have to run any other command after that file is changed?
The information on this thread is not very complete and it doesn't work on 1.7 anymore.
After trial and error I discovered that the problem was the wrong cscfg. To test it:
Change the ServiceConfiguration.Local.cscfg from the Azure project
Open the Windows Azure SDK Environment as an Administrator
Change the Directory (cd) to the Azure project where the ServiceConfiguration.Local.cscfg file is located
run the command csrun /update:[DEPLOYMENT ID];ServiceConfiguration.Local.cscfg where [DEPLOYMENT ID] is the number in parenthesis following the label deployment (XX) of the Azure Emulator
Also I noticed that the csrun /update:[DEPLOYMENT ID];ServiceConfiguration.Local.cscfg will terminate the deployment if we are debugging the solution (Start Debugging - F5), it will work normally only with (Start without Debugging - Ctrl F5) option.
Added just in case it helps anyone.
Related
I created a function app on Azure Portal with below configuration.
And I created a simple HTTP trigger Function App on VS 2019 version of 16.7.6. The function is working successfuly on local machine. When I want to publish it to Azure, it returns below error;
Publish has encountered an error. The Publish URL
https://waws-prod-am2-xxx.publish.azurewebsites.windows.net/ is
unreachable. The application may be stopped, restarting or
unavailable. Try again once the publish target is available.
The publishing summary is;
When I check the publish profile on VS (.pubxml file), I see the line
<PublishUrl>https://waws-prod-am2-311.publish.azurewebsites.windows.net/</PublishUrl>
But it should be
<PublishUrl>http://myfuncappdss.scm.azurewebsites.net</PublishUrl>
I change it manually and there is any other error that is not detected
Publish has encountered an error. Publish has encountered an error. We
were unable to determine the cause of the error.
It hasn't published for 2 days. Before, I published successfully. I search it on google but I couldn't find any clue.
Btw, I can reach the FTP file of the function successfully. And the function running successfully on https://myfuncappdss.azurewebsites.net/ site.
I tried it with az command also but it wasn't work, too. All my teammates can't publish also. So, the problem is not just about my computer.
Why is the PublishUrl set with wrong URL?
When I check the publish profile in Visual Studio (.pubxml file), I see the line:
<PublishUrl>https://waws-prod-am2-311.publish.azurewebsites.windows.net/</PublishUrl>
But it should be
<PublishUrl>https://myfuncappdss.scm.azurewebsites.net</PublishUrl>
I changed it manually and then it started working fine.
Step 1: Do the above URL changes and save the .pubxml file
Step 2: Close Visual Studio.
Step 3: Open your project in Visual Studio.
Step 4: Now publish, it should work as expected…
Here we have successfully deployed the Function App.
Update:
Thanks for Aybuke's aharing, this is the reason of the problem:
The problem base is about function publish profile. When I follow the steps, (Go to Azure Portal-->Go to function app-->Overview menu-->Get Publish Profile) I can download the publish profile of function. So, I can see the publish settings of function. "publishUrl="https://waws-prod-am2-xxx.publish.azurewebsites.windows.net:443"" This line is in the publish profile file that I downloaded. But it should be "publishUrl="https://myfuncappdss.scm.azurewebsites.net"". That is why the published zip file is sent to wrong url. So, there are some problems while creating function on Azure Portal.
Original Answer:
Did you encounter this error?
I notice you change publish url to http://myfuncappdss.scm.azurewebsites.net, please change it to https://myfuncappdss.scm.azurewebsites.net and try again.
If I use http, I also can not publish my function app. I don't know why the publish url is not what you want, but the az command should work. Any details when you use az command?
Change http to https, it should work.
I had this issue and the problem was on the App Function Settings.
In Networking, Inbound Traffic had Access Restrictions ON.
I had to add my public IP Address and then I was able to publish.
I've created a Linux App Service running .NET Core 2.2 on Azure. When I go to the deployment center and choose Azure-Repos/ Azure-Pipelines as the source control and then select my MVC Core repo, i'm required to enter a Startup Command, but deleting the command afterwards in the App Service's Configuration - General-Settings doesn't actually prevent the website from running?
Edit:
Actually, if I don't delete the Start-up command after deployment my app wouldn't run!
Well yes, AFAIK, it is true that the Startup command should be optional in the Deployment Center configuration blade, like it is in the Azure App Service Deploy task, unless it's needed for some other specific reason.
I shall check with our internal teams about this and get back with more details as I have them. Thanks for the question!
Update:
#jcmontx We have created a workitem to track and fix this. Please note that there are some other high priority changes planned for Linux Web App continuous delivery which will have effect on how startup command is handled. This means we will have first wait for these to complete before processing the requested change. Thanks for your patience!
I had the same problem. The only solution I found to this was to:
Add a random comment as Startup Command (your build may fail the first time) when setting up the Pipeline in the Deployment Center.
Then go to Azure Pipelines -> Releases -> Select YourPipeline -> Edit -> Tasks -> Select "Deploy Azure App Service"
Scroll down the options and you'll find "Startup command"
Remove your previous input (step 1)
Save
After installing Visual Studio Enterprise 2017 (Version 15.1 (26403.7)) my Azure Cloud Service does no longer build and gives me the 'Error WAT200: No default service configuration "ServiceConfiguration.cscfg" could be found in the project'. Although it still works fine with Visual Studio Enterprise 2015. (The right TargetProfile is also specified...)
I ran into this last night.
It actually happens when you rename Cloud Service configurations away from Cloud and Local.
In my case, I had deleted the Cloud configuration and created a new, differently named one.
By ensuring that the configurations are called Cloud and Local, the Cloud Service projects will build again using "Resharper build", and (most likely) under "Lightweight solution load".
The configurations can be renamed by right-clicking one of the service roles under the Cloud Service node in Solution Explorer, choosing Properties, then opening up the "Service Configuration" dropdown and clicking <Manage...>.
Now, in the resulting dialog, the configurations can be renamed:
The following bug report got me on the right track:
https://youtrack.jetbrains.com/issue/RSRP-450390
The best way is to change the service configuration prefix in ccproj of your project, add yourprojectname.configurationname
Dot is the life saver.
<ServiceConfigurationPrefix>yourproject.ServiceConfiguration</ServiceConfigurationPrefix>
Add these in itemgroup:
<ServiceDefinition Include="yourproject.ServiceDefinition.csdef" />
<ServiceConfiguration Include="yourproject.ServiceConfiguration.cscfg" />
Make sure you have renamed your cscfg files from the folder it resides.
Reload
Bingo. It works.
Ok I found it, after disabling the 'Lightweight Solution Load' (which in VS 2017 u can disable by right click on the Solution and then Disable Lightweight Solution Load), the error disappears and the Cloud Service builds again.
Similar to Rishikesh mentioned, but I added a service config entry
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
to the ccproj. Then copied a configuration, e.g. Production and named it ServiceConfiguration.cscfg. Then reloaded the project. That got the ReSharper to build, but MORE importantly for me at the moment was to figure out how to the get Azure DevOps pipeline to build the solution with multiple Classic WebRole projects in it. That was failing for the SAME reason.
I am getting the following error:
Error: The process cannot access the file 'C:\DWASFiles\Sites\mywebsitename\VirtualDirectory0\site\wwwroot\newrelic\NewRelic.Agent.Core.dll' because it is being used by another process.
In the Running deployment command... log file when attempting to deploy an Azure website from Github.
Would appreciate any pointers as to what could be causing this.
UPDATE: Turns out this is also failing when publishing directly from VS.NET with the following:
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4196,5): Warning : An error was encountered when processing operation 'Create File' on 'NewRelic.Agent.Core.dll'.
1>Retrying operation 'Update' on object filePath (mywebsitename\newrelic\NewRelic.Agent.Core.dll). Attempt 1 of 2.
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4196,5): Error : Web deployment task failed. ((06/07/2013 23:54:58) An error occurred when the request was processed on the remote computer.)
This was working before and I am not sure why it would have stopped.
NewRelic recommend stopping the website to unload the file and allow the deployment to go through.
As an alternative, you can set COR_ENABLE_PROFILING to 0 in your app settings on the configure tab to temporarily disable the profiling, which should then allow you to continue with the deployment while leaving the website operational throughout.
Instead of stopping the website you can temporarily turn off New Relic monitoring via the Configure tab on manage.windowsazure.com:
Configure > developer analytics > select "OFF" > Save
Deploy
Configure > developer analytics > select "ADD-ON" > Choose Add-on from dropdown > Save
Worked for me, both with a regular deployment from VS and an automatic build from VSO.
This is a known issue with the New Relic .NET agent for Azure Websites when performing an upgrade of the agent. The workaround is to stop the website to release the dll, finish the deployment and then restart the instance.
https://newrelic.com/docs/dotnet/azure-web-sites#h2-1
Not really a solution but more of a work-around, in the publish dialog view a preview of the changes and uncheck the NewRelic.Agent.Core.dll file so that it doesn't get published.
None of these answers work for me anymore. I have an Azure Basic tier website plan, which hosts multiple actual websites.
If I don't stop the website, I get the error mentioned above (newrelic.agent.core.dll is in use)...
If I do stop the website (or all of them), I get an error saying that the publishing endpoint isn't available.
If I go to the configure tab and disable the AddOn, we still get the error mentioned above (newrelic.agent.core.dll is in use)...
Pretty much we just republish over and over again with different permutations of the above until if works. It took me hours the other day, took me 10 minutes today.
If you are using webdeploy, then you can configure your webdeploy settings so that it ignores the file. However, if you do that, you will manually have to deploy any updates to the new relic agent.
I had a similar issue with the new relic log file being locked, and solved it by:
Moving the new relic log file to a subdirectory of the web root (e.g. \newreliclogs)
Adding 2 lines to my powershell script that configured the skip directive to ignore that whole directory. e.g. (where destBaseOptions is of type Microsoft.Web.Deployment.DeploymentBaseOptions
$skipDirective = new-object Microsoft.Web.Deployment.DeploymentSkipDirective("NewRelicLog","objectName=dirPath,absolutePath=.*\newreliclogs$")
$destBaseOptions.SkipDirectives.Add($skipDirective)
Depending on how you are using webdeploy, the configuration is achieved slightly differently, I used the following links to help me piece it together:
https://technet.microsoft.com/en-us/library/dd569089(WS.10).aspx
https://msdn.microsoft.com/en-us/library/microsoft.web.deployment.deploymentskipdirective(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/dd543313(v=vs.90).aspx
http://blogs.iis.net/jamescoo/archive/2009/11/03/msdeploy-api-scenarios.aspx
http://forums.iis.net/p/1192163/2031814.aspx#2031813
And I used the powershell script from the Octopus Deploy Library at https://library.octopusdeploy.com/#!/step-template/actiontemplate-web-deploy-publish-website-(msdeploy).
I have set up a cruisecontrol.net build server. When running it in console mode it works fine, but when trying to run it as a windows service it doesn't work. The log file shows the following message:
ThoughtWorks.CruiseControl.Core.CruiseControlException:
Source control operation failed: No VSS database (srcsafe.ini) found.
Use the SSDIR environment variable or run netsetup.
The ssdir is set in ccnet.config, so what am I missing here?
Not sure if it's applicable but when I had problems switching between the Console version and the Service version it was down to access rights for the user I was starting the service as.
Perhaps the Service does not have access rights to the srcsafe.ini file and your account does(assuming that's what your using to run the console).
Apologies if I'm way off the mark, just trying to help!
I ran into similar issues when setting up our CI environment at work. If you can get log-in permissions for the service account you are using, you can log in as that account and run CC.NET via the console and debug your issues.