I need to investigate if this is possible or not.
The scenario is that we have an api (.net core 6.0) where we will have two controllers
WeatherForecastController and HomeController.
Now the question is, if it would possible to deploy each controller inside two different Azure App Services or two different App Service instances?
First of all, to answer you, this need of yours is currently unattainable.
WHY
1. From the perspective of the project's release file
In .net6 project, when we build the project, and it will generate .dll file which contains all the files(Controllers and Views and so on).
2. Analyze from the publishing process.
Simply put, after compiling the project file, it is finally uploaded to the wwwroot folder of the kudu site.
So the current requirements, from the perspective of the app service, cannot interfere with any behavior of the controllers in the project.
Related
I have a .Net core app developed using Visual Studio 2019 and deployed on Azure app service. I have function app as well in the same solution. I have to do couple of things and then redeploy to Azure app service.
Add one .cshtml file
Modify one .cshtml file
My question is, how to deploy the CSHTML file only to the Azure app service? Without affecting the existing functionality of application.
As per my understanding, if web app is deployed in Azure app service then the whole thing (solution) has to be deployed even though there are/is very small code modifications.
Please let me know.Thanks.
Even if you have Web App and Function App in the same solution, they should be separated units of deployment. That said, your deployment pipeline should be separately triggered for Web App and Function App.
From the technical point of view(or architecture) there's no concept of "solution". Solution(.sln) is a Visual Studio specific being and even though it's supported e.g. in VS Code, I'd never treat it as deployment unit. Especially in your scenario, when in fact two separate services are responsible for handling your code.
Even if you deploy Function App as a part of the same App Service Plan as your Web App, it's still a separate Azure service. In such a scenario they only share compute.
Yes its possible if you have access to kudu deployment center you can perform manual add/update information , please visit below URL:-
https://[yourAppName].scm.azurewebsites.net
You can also navigate to this site using the azure portal , once you open the app service blade you will find the kudu deployment center option in the bottom left of the menu.
It will provide an online file explorer of your application hosted on the app service and from there you can migrate to relevant folder and perform add/update.
We are having a application developed in MVC 4.
Here are our scenarios:
1) we are following plugin architecture, so we are having other projects which can plugin into the main web application.Right now we are using installshield to deploy our dlls from other projects into the main web application.
How can we do when publishing the main web application as Azure App service.
Is there any feature in Azure so that we can remove the install Sheild and use some properties in Azure to move the dlls from other projects to the main web application folder.
2)We have logging feature enabled so the logs are maintained in local File store under AppData folder and upload the same log file to Db and delete the local log file? How can we achieve the same if moved to Azure App service?
3)Our MVC application calls the another Service application using rest Api calls.Currently we are mentioning the service details in config file under MVC application.
if we are moving to Azure how about the configuration properties mentioned in my MVC Application to call the Service project.
To start with, I would like to deploy my REST Api service project to Azure.My project is a class library and please help how can move my service project to Azure App service and get the server name.
1) Plugin Architecture
We had a similar requirement but we were not using InstallShield for copying plugin DLLs to our web app, instead what we did was created the following folder structure:
-- MVC Application
---- bin
---- App_Plugins
------- Plugin1
------------ Release DLLs
------- Plugin2
------------ Release DLLs
-- Plugins (actual source code)
---- Plugin1
---- Plugin2
and set the output directory of our Plugin 1 and Plugin 2 to point to the ..\App_Plugins\Plugin1\
and we simply published this app directly to Azure Website and that worked like a charm.
Then we found out about CI/CD process on VSTS and that changed everything, it gave us a more elegant way of managing all of this. Can provide more details if you need that.
2 Logging Feature
If all your logging code & logic for moving all this to DB is within the application, then you should not have to worry about anything and it should work without any challenges as long as you setup your DB connections correctly.
3 REST API settings in config file
The web.config file of your MVC application is published along with the rest of your application. so, as long as your settings are mentioned in the web.config and they work locally, it should all work fine in Azure as well.
Start here - https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-deploy
Ensure you already have a Azure account, and of course visual studio has the Azure SDK installed (it may be required).
Case: The solution consists of two Web Apps configured in Azure App Service. The first one hosts a backend API (Asp.Net Core) and the second one an SPA frontend website.
In this project we decided to drop the application server(Kestrel/Node.JS) altogether from the frontend Web App, since there is no real need for that. Application is a simple Single Page Application which can be hosted directly from IIS. The application itself works perfectly. However, now when we are implementing our CI/CD-pipe we have faced an issue. The same build needs to work in both QA and Production environments. But how can we pass the API-address from Azure App Service Application Settings to the SPA-application which is running in the browser when there is no Application Server and therefore serverside code?
We can't modify the Continuous Integration -pipe - the build needs to be exactly the same in both environments. However, we could in theory add one step to the end of our Continuous Delivery -pipe and e.g. modify web.config to pass Custom Headers or add a static file that tells what environment is in question and read that from the application, but I'm not sure if that's the right way to go. Is there any App Service Extension or feature I'm unaware of which would allow passing variables from Azure App Service to the browser?
What we opted for, is reading out a json settings file which we set with a deploy step.
So in your codebase you have a file which always get read by the application with a default dev setting.
In our VSTS setup we use the 'Azure App Service Deploy'-task for deploying the code.
In that same task you have a section that is called 'File Transforms & variable Substition Option'. The XML stuff is for web.config only but for the JSON variable substitution portion you can specify file names.
I am trying to get continuous integration configured using Azure. The process I have followed is exactly as detailed by Continuous delivery to Windows Azure using Visual Studio Online
This process works perfectly! I check-in, it builds, and deploys to the Azure website. However, as soon as I add a second web application to the solution, after the CI build kicks off and then completes, the only thing that gets published to the website is the bin directory of the second web application! (Updates to the first project are successful, though)
Given the scenario, I don't understand why the dll's of the second application are being published to the bin directory when the rest of the application(i.e. content files) are not. There is no reference from app1 to app2 so the dll's shouldn't be brought in by reference.
How can I configure this so that it will also publish the second web application?
You can tell Windows Azure Web Sites which project within a repository to deploy using a deployment file.
Add a file called .deployment to the root directory of your repository, with this content:
[config]
project = src/MyApp.Web
You can specify the folder containing the web application, or the actual .csproj or .vbproj file for the application.
If you have two sites in a single solution/repository and you want to publish them both, you will need to use two separate Web Sites, and use App Settings in the portal to specify the project instead. Create the sites, and for each, add a setting called Project in the Configure page, with the path to the directory or project as before.
More info: https://github.com/projectkudu/kudu/wiki/Customizing-deployments (Kudu is the system that actually handles deployments on Azure Web Sites)
I have a situation where I need multiple .cscfg and .csdef files - i.e. I'm deploying to multiple Azure subscriptions and each one needs different endpoints and certificates etc.
I've looked into using XDT transforms to change the .csdef file on build to swap the certificates etc. but I'm not 100% happy with doing this as it seems like the scope for error is pretty high... As well as potentially having many different configurations.
Is it possible to have multiple Azure Cloud service projects in the same solution for a single web app? If I just try to add a new one in, VS creates a new MVC app for it and there doesn't seem to be any way of changing which project the web role uses.
Or is there a better way of changing things like certificates for publishing web roles to Azure?
You can certainly have multiple .cscfg files in a single Windows Azure deployment project. Visual Studio already creates a [your-project-name].Local.cscfg and [your-project-name].Cloud.cscfg for Windows Azure projects. There's nothing stopping you from create a [your-project-name].Foo.cscfg configuration either.
The problem (as I'm sure you're noticing) becomes the .csdef. Only one of those in a deployment project. The transform approach is one solution. Another option I've used in the past is to create multiple Windows Azure deployment projects in the solution - one project per configuration / target environment. Each project is then mapped to the same MVC project. This keeps the Visual Studio tooling working like it expects to work. The downside is that you have more configuration to manage (i.e. have to keep all the .cscfg and .csdef files in each project in sync). Works, but kind of painful.