I have an Azure .net backend working just fine locally. But when I deploy to Azure, I get this msg when I use the azure test page to test the deployed service.
Found conflicts between different versions of the same dependent assembly 'AutoMapper': 3.2.1.0. Please change your project to use version '3.2.0.0' which is the one currently supported by the hosting environment.'
So, my first thought was to downgrade to AutoMapper 3.2.0, but then I get into difficulty with my existing mappings that worked just fine with AutoMapper 3.2.1.
My question is why does Azure Region 'East Asia'(where my azure mobile service is deployed) have this issue ?
Do other regions suffer from this ?
What should I do ?
The problem was that I had local copies of AutoMapper binaries in my bin folder which got deployed to Azure. So, removed them and conflict was resolved.
Related
deployed Lumen micro services using azure devops and suddenly it started giving 500 internal server error after successful deployment.
Set the same package version on deploying to Azure App Service as the package version that worked locally, for local environment.
App Service runs your app in production mode, so you need to make sure that your project works as expected in production mode locally. Depending on your composer.json, different packages may be installed for production mode (require vs. require-dev).
Thanks, for the answers but I got it fixed by adding flag --ignore-platform-reqs to composer install in yml file.
We have a web app project that still uses NuGet for content packages management (jQuery, Knockback, knockoutjs, etc.). We are trying to convert to use LibMan, and running into an issue where some older packages do not exist (for instance walltime-js). How do we work around this issue?
Try using a different provider. The current default, Cdnjs, is a curated catalog; the other two providers, JSDelivr and Unpkg, host any package that's available in NPM and thus have much broader catalogs.
I have a web app, and I've setup VSTS to create a package in build, and then deploy it using release management.
It puts all of the result in the wwwroot of the site if I look at it in ftp so I get:
/site/wwwroot/
/wwroot
/
This doesn't run and I get a 404 error.
If I use the URL and go say /wwwroot/images/ it returns it just fine.
The app is set to use .net core and I'm doing a self-contained package.
How do I get VSTS release to put the files in the right place and what is the right place ? I can't find any documentation on this anywhere. Everything is to do with Windows.
Also, what linux target should the dotnet application be set to for self-contained? I have it using ubuntu but I'm sure that's wrong and it's something else.
Please use Azure App Service Deploy task with 4.* (preview) version instead, and deploy again:
I had a similar issue and I responded here. Essentially you need to have a startup command pointing to your DLL because Dev Ops deploys the package in a different way than VS.
Deploying .Net Core to Linux WebApps on Azure with DevOps
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
I have a PHP Azure project which I have to manage with Powershell cmdlets. One of these, Publish-AzureServiceProject doesn't seem to be detecting file changes so these are not updated on the cloud (even though no errors are displayed).
I have remote desktop'd into the machines and the code is definitely not updated from weeks ago.
If I deploy to the local emulator, it is fine but this is much more obvious because it displays "removing old package" and "creating local package". The cloud package definitely contains the latest files, so the packaging is working fine.
Can anyone tell me how to force the publish to update the files on the cloud and more importantly, why this is not happening? Also, if I force the update, will it deploy to a new box and get a new IP Address?
Thanks.
It seems to work now.
I have removed and reinstalled azure libraries from my machine and created a new project from scratch and copied the original files over into it. I have not included diagnostics (not sure if that's an issue) and I have modified the Publish-AzureServiceProject script to select the subscription each time before it publishes.
It is possible that the subscription confusion was not helping (I have two Azure subscriptions and it might have used the wrong one at some point and done something weird) and also it was possible there was some conflict with various versions of the Azure SDK since I have been using it for over 6 months but at the moment, all is good.
A related article on my blog here: Problems with PHP Azure
Thanks for the interest