I am trying to stand up a sitecore site inside a fresh app service in Azure. This already works in our production Azure account, but we would like to see how to set it up from scratch.
The build and deploy succeed in pushing it out to the app service, however, I am getting:
Could not load file or assembly 'System.Web.Http.Cors, Version=5.2.3.0
and no further information. I verified that system.web.http.dll is present in the bin folder. I read in some other articles that sometimes the wrong version could cause issues but this works on my work machine. Is there another step I need to do to make this work in an app service? Some configuration change, maybe?
The dll is missing in the published (deployed environment). That is the reason why it is working in the local i.e. Visual Studio but not in the Azure Website Environment.
Just do Copy Local = true in the properties for the assembly(System.Web.Http.Cors) and then do a redeploy, it should work fine.
If Copy Local is already set to true and you cannot update the WebApi because of dependencies, there is that trick to set Copy Local to false, build, then set Copy Local back to true and build.
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.
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!
A website with webjob not deploying to Azure.
I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.
The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.
The solution will build and work locally fine.
The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.
However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!
If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.
It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.
I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.
I have been battling this for a couple of days now an I'm a bit stumped!
This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.
I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.
You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set
That's the root case of problem.
You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.
I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)
So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.
See this
A couple of days ago, Microsoft released the engine they're using to do git deployments to Azure. I've had a task on my TODO list for a while to get that kind of functionality set up on my DEV IIS server, so I'm interested in trying out Kudu for that purpose.
The "Getting Started" document shows how to run the web front-end, but everything in there uses "http://localhost:PORTNUMBER" type URL's for git repositories, site URL's, etc.
I realize this is probably getting too far ahead of them, but I'm wondering if anyone has pointers for how to set it up using real domains on "regular" IIS instead of all of the localhost bits?
This is an old question, so I'm giving an updated answer with more current info since I just worked through setting up Kudu on an internal deployment server. The currently selected answer only deals with if you are directly running Kudu from within a development environment.
If you are deploying to a "production" type environment and don't want to install Visual Studio on the target server, there is a good guide on the project website on github.
https://github.com/projectkudu/kudu/wiki/Deploying-to-a-server
On the target server, you will need to install:
MSBuild ( http://go.microsoft.com/fwlink/?LinkId=309745 ) - comes with Visual Studio
NodeJS ( http://nodejs.org )
Git ( http://git-scm.com/downloads )
Back on your development machine, clone the git repo and build using the "build.cmd" file, following instructions in the above link.
In running build.cmd I got several test failures which blocked the build from producing artifacts. These were all related to Mercurial, which we don't use. Installing a Mercurial client didn't make them magically go away, so I disabled the tests rather than sink a bunch of time into debugging my environment.
Your build output will indicate the failures. I disabled by commenting out the [Fact] attribute.
These are the tests I disabled:
tests/Kudu.Core.Test/HgRepositoryFacts.cs (all tests)
Once you have a successful build that has created all the items in the artifacts you can move to deploying the Kudu website and web service code. The below instructions are for setting up a distinct web application instance, rather than dumping everything in c:\inetpub\wwwroot, which is how the instructions read.
Copy "artifacts\Release\KuduWeb" to the target area on the server where your website will run from. I run my kudu install with a separate host header, but you could as easily use a separate port or run as the root website. This directory will be the root for your web application.
Create an empty "App_Data" folder immediately under the KuduWeb folder.
Copy "artifacts\Release\SiteExtensions\Kudu" to the same level as the folder in step 1 and rename to "Kudu.Services.Web". This location is set as a relative path in the KuduWeb web.config file - setting serviceSitePath.
Open IIS Admin and create a website pointing to the "KuduWeb" folder from step 1.
Configure the app pool from step 4 to run as "LocalSystem". This is required to manage IIS Sites.
Create a new folder "apps" at the same level as KuduWeb. This is where deployments will be sent. Note: this location is controlled in the KuduWeb web.config file - setting "sitesPath"
Change filesystem permissions to grant "Users" full access to the "apps" folder created in the above step.
On starting my Kudu website, I got the following error.
Parser Error Message: Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
For some reason it didn't copy the appropriate MVC version into the deployment artifacts.
If you hit this error, the MVC 5 file can be obtained via NuGet. I found that my source code was built against 5.1.0, so this is the appropriate link:
https://www.nuget.org/packages/Microsoft.AspNet.Mvc/5.1.0
In order to extract the dll, I set up a new dummy project and used NuGet to pull down the dll via the package manager console.
Install-Package Microsoft.AspNet.Mvc -Version 5.1.0
Once you get the binary, copy it from package directory ( .\packages\Microsoft.AspNet.Mvc.5.1.0\lib\net45\System.Web.Mvc.dll ) to the website bin directory on the target machine.
At this point you are up and running. Use the web interface to create your application. It will create a subfolder under the "apps" directory with a tree that should be self explanatory. It will also have created two new websites for your application:
kudu_{your-app-name}
kudu_service_{your-app-name}
In a production situation, you should create an additional website running on appropriate port/host header that points to: .\apps\\site\wwwroot
Now you can add a git remote for your deployment. Go to your source location in a git console (ex: Git Bash) and add the remote as identified by Kudu. Note: you may need to change localhost in the url to be the appropriate server name.
git remote add deploy http://:52711/your-app-name.git
Push your code to the new "deploy" remote and see what happens. You should see all the normal push messages, plus the build output.
git push deploy master
My initial push failed to build and deploy due to "node" not being recognized. It was in the path, so a server reset convinced the path environment variable to be refreshed. You may find additional errors to work through. For instance, I had an issue with MSBuild being imported and causing a hiccup.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Visual Studio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.
YMMV, but these are all solvable problems now. Good continuous deploying!
The project automatically sets up two websites on IIS for each application you add using the web front end. Kudu doesn't automatically map the bindings for them but it's relatively easy to open IIS and find the two sites named "kudu_appname" and "kudu_appname_service". The service website is the one that you point GIT too and the other one is the site itself. Just add public bindings to them by right-clicking and "edit bindings". You can then add public hostnames to them.
This is the easy part. The hard part that I'm still working on is getting authentication working so any random Joe isn't able to push to my kudu repository!