I am starting a new project (let's call it MyWebProject) which will have
MyWebProject: a front-end app with AspNet Core serving a SPA with Angular2
MyWebProjectAPI: a back-end app with AspNet Core connected to a DB and exposing RESTful API
They don't have inter dependencies since MyWebProject access MyWebProjectAPI through http requests only. So we could say they are independent.
I have a single domain www.mywebproject.com linked to a single Azure App Service mywebproject.azurewebsites.net and I want to have both projects (front-end and RESTful API) deployed under the same Azure App.
If I access with a web browser www.mywebproject.com I want to access the front-end. I don't mind where the RESTful API is deployed (I'm guessing in a virtual directory under the same App Service IIS?)
I am also planning to have continuous deployment where pushing changes to a master branch in a Git repository would trigger a new deployment (ideally both deployments are configured separately but I don't mind that much)
The question is:
How to structure my solution/projects and what approach should I follow?
I am considering One single solution with the 2 main projects (front-end and back-end) plus library projects required by the back-end project, and therefore I am assuming they all would have to be in the same Git repository?. Would that be a problem? or is it better to have them in separate Git repositories and separate solutions? (this option would also be ok)
What would be the approach to follow when deploying into the same Azure App service? To use a virtual directory because they both are web projects (both have a wwwroot)?
Another option could be one single project for both RESTful API and front-end with one of the controllers simply serving the SPA and the other controllers acting as the API resources. This would certainly simplify everything, but somehow I wanted to have both projects independent.
Any reference, article or opinion would be appreciated.
I work with an app where we have one solution that two different Web Projects, both living at the same domain and both being deployed using continuous deployment. It works out fine. Here is how it works:
Have one Visual Studio Solution
Under that solution have the two web projects
In the Azure Application settings for your App Service, scroll to the bottom under "Virtual applications and directories" and set up a Virtual Directory for MyWebProjectAPI. Virtual directory would be "/MyWebProjectAPI" and Physical path would be "site\wwwroot\MyWebProjectAPI"
Create the deploy.cmd for doing the continuous deployment in the solution folder, just like normal
Edit the deploy.cmd to also deploy the second web project.
You'll find a line for the first project that looks like:
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProject\MyWebProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
IF !ERRORLEVEL! NEQ 0 goto error
Copy that code and update it to build the API project into the virtual directory (notice the first path changed as well as the PackageTempDir):
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProjectAPI\MyWebProjectAPI.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%\MyWebProjectAPI";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
IF !ERRORLEVEL! NEQ 0 goto error
After you deploy, your front end will be at www.mywebproject.com and the api will be at www.mywebproject.com/mywebprojectapi (of course you can rename everything).
Is this the right way to go? There are pros and cons. In our case we needed to do it this way because the 2nd Web Project came from a third party and had to live at the same domain. And that's a big pro - you avoid any possible cross domain issues. Also you have a lot of consolidation with only one DNS entry to worry about (including SSL certificates) and only one App Service to pay attention to.
I could argue, though, that it would be better to let your code run in two apps to get more distinct monitoring and scalability. You said you only want one App Service right now, so either way you don't get the ability to scale. But if you set up two projects as different apps, you could eventually move them to separate App Services later if you needed to scale one and not the other.
If you did want two separate apps with different DNS entries, you could still have just one solution file. I don't have an exact example of doing this, but you would have both apps monitor that branch. So a build would kick off in both apps when you pushed. But you would add a setting in your Azure Application Settings saying which project should be built, and you'd modify your deploy.cmd file to look for this parameter to build the right one.
Related
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.
Apologies if this question has already been answered. I've tried looking around, but may not have done a great job!
My azure deployment consists of 4 web sites deployed from VSTS that all share common web assets hosted on an Azure CDN. I would like to create a single "build" (or release) in VSTS so that I can build all the client-assets at once and deploy them to the CDN endpoint as well as the 4 running app services for fallback.
My initial approach used FTP tasks for the web servers. This worked but took almost an hour to ftp 500+ files to each website. I then attempted the approach mentioned here. Though I was able to zip up the assets, my drop file had the structure of:
- assets
- WebAssets.zip
Eg. "WebAssets.zip" was just a compressed copy of "assets" and I was unable to deploy this file to the proper location on the websites, "/site/wwwroot/wwwroot".
Is there a better way to copy these assets to each web service? Here is the structure of the "ftp" version of copying the assets:
Any help or direction pointing would be appreciated.
Update: just wanted to clarify that the current process does indeed work. It just takes between 30min and an hour to complete. I just want to make sure I am doing it correctly and that there is not a better way.
With Azure App Service Deployment task, you need to check Publish using Web Deploy option if you want to extract the zip folder.
On the other hand, to improve the performance, you can setup a private build agent that has the high performance (e.g. Network, Memory, CPU)
Deploy an agent on Windows
I have a deployment script to deploy an application to a website called admintools3t. After the deployment, I see the folders for the app directly underneath that website (when viewed in IIS). The code is deployed to the folder D:\applications\admintools\admintools_wwwroot\myapp1, which is where I (think?) want the code. However, my website is the generic site that needs to host multiple applications, myapp1, myapp2, myapp3, myapp4.
Here is the call I make to use msdeploy to perform the deployment:
call D:\temp\AdminTools\%APP%\%APP%.deploy.cmd /Y "-setParam:name='IIS Web Application Name',value='admintools3t'"
I'm doing this on-the-fly switch on the value because I have multiple environments where I will be deploying to and rather than having multiple profiles, I do this on-the-fly switch, which appears to be working.
How can I tweak this command or add additional parameters so when I view the website in IIS that I see a myapp1 underneath admintools3t?
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.