Is it possible to create .NET MVC Core C# solution with multiple apps or modules and based on client selection of which app/module he wants to have I can deploy only selected apps/modules?
I need to deploy the only selected app/module and not include other apps/modules and the solution should work without breaking dependencies (such as classes).
I dont need to deploy each app in different C# application because that requires to install them on separate ports on IIS.
Similar scenarios I can refer to are: Zoho CRM or Odoo, user can select apps/modules that he likes to enable and start using them in his workspace
Related
We've developed a MVC application that uses a SQL database to store data. We chose the approach to have a separate web app in azure (customer.ourdomain.com) per customer, as well as a separate database per customer running on our SQL server. This database is pointed to by the MVC application in the web.config file.
I've also created a website where new customers can register to use / try our product. Now every time somebody registers for our product I want the following to happen:
Create an Azure web app with the name of the company / customer that registers
Create a new database including the tables and relationships that our application needs
Publish the stable release of our application to the web app in azure and configure the application to use the newly created database
I've managed to do the first step using Azure ARM templates and the second step using dacpac and the Azure API, but I don't know how to use TFS (or any other method) to publish a stable release and change the connection strings before publishing the application to the azure app. (I've not even managed to publish anything with C# code).
Is the approach I'm taking in general okay or should I take a different approach? What is the best way to publish a stable release to the web app and most importantly, change the connection string so the published version will connect to the new database?
If you get vsts to package up your stable release and upload it to blob storage, you can reference that web app as part of the ARM template deployment, ie. include the web app code deployment along with the web app service itself.
This page shows how it can be done. I think you can also get the web app and ARM template to pull a release from vsts (I'm pretty confident you can do it via GitHub) using the app service's source control integration/CD settings as well, but cant find any details on this.
So my application is composed of a handful of separate .NET components that all run in Azure. To give you an idea of what's involved:
A main ASP.NET MVC5/Web API 2 REST service that runs as an Azure website (I think they renamed these to web apps?).
A SQL database that the main REST service uses.
Another internal Web API REST service that the main REST service talks to that runs as an Azure website.
An Azure storage table that the the internal Web API REST service uses.
3 scheduled jobs (just .NET exe's) that do work in the background and also talk to the main SQL database.
All that's running great in Azure right now. My problem is automating the deployment and configuration.
Right now it's all manual. I right-click and publish both web apps from Visual Studio. I build and FTP up the web jobs. The database and Azure storage already exist so I don't have to re-set them up.
But say something bad happens - a datacenter goes down or something. I'd like to be able spin up a new version of my app (with all those components) that is ready to go with minimal effort.
I'm pretty new to the world of Azure so I'm not sure where to start. What are my options?
You are looking to automating deployments in Azure. I recommend to use ElasticBox to solve it.
To achieve the automation you will need to create a box for every different service or component you need to deploy (a box is the abstraction unit that uses to define the installation and configuration of the deployment of a service or application in any cloud).
It's possible also to create boxes based on VM Instances, VM Roles, or Worker Roles and also automate the deploy of Microsoft SQL Servers. Let's say near every option offered by Azure.
Then with those boxes completed (that can be customized and reuse your legacy code from your previous manual installation), you can deploy the multiple vms with near no manual intervention, just one click or a command with some parameters.
A box includes the variables necessary for your deployment (you can set default values for those variables) and your legacy scripts (In this case probably PowerShell, but they could be bash, python, perl, java, or any other language)
When you deploy your boxes:
Creates a Cloud Service or VM in the location that you choose and with the Azure configuration that you preconfigured. It takes care of provision the vm in your Azure provider, or near any other cloud provider in the market.
Installs, configure files with your specified variables and execute your SQL or Web services that you have defined.
Other ways to interact with the service:
Jenkins' Plugin could be used to build a CI environment connecting your code updated or a Pull Request with automated deployments in Azure or any other public cloud.
Command line tool that enables to do VM deployments of your boxes and also you can manage your deployed vm instances with it.
Azure Resource Manager (ARM) is intended to solve exactly the issues you described.
The basic idea is that you use a JSON template to describe all your services. You can then give that template to ARM and it will create the services as defined in the template. If you want to make a change, instead of doing it imperatively (via powershell or manually in the portal) just update your template, pass it to ARM and it will make whatever changes are necessary to make the services match your template.
Some resources:
ARM talk at MS Ignite 2015
ARM template language reference
Quickstart templates on GitHub
Azure Resource Explorer - view ARM templates of existing resources
Resource Group Deployment Projects in Visual Studio
I think your looking for something to help you handel deploys to your windows Azure servers. If that is the case I recommend looking into Jenkins CI. There are many resources available online you can look into in terms of having Jenkins and Azure work together.
I have an existing product that runs in .Net 4.5.1 as a windows service. It currently hosts some WCF services for controlling and reporting on the product.
I now have a requirement to host a basic web application (ideally ASP.Net, but HTML and JS would do) within the windows service as well, for configuring the product.
We ideally don't want a separate install of a website/IIS as a requirement, so I really need to be able to do all this from the windows service itself. I will be calling into the WCF methods for some functionality, but I would ideally be able to run some .Net C# code as well.
I've looked about and all the stuff I find is for hosting web services within a windows service, or incredibly old stuff from 2010 or before.
I've looked into the ApplicationHost.CreateApplicationHost stuff, but the one tutorial I found involved adding stuff to the GAC, setting windows environment variables etc, which again, I would rather avoid and keep my stuff all fairly isolated.
I need to design an HTML 5 responsive, and simple app that should work on both internal Win server and on Azure.Our Client wants to check out Azure but maybe later he will want this app to be on its own on premise servers. Our Developers are almost all .NET back ends, with basic knowledge in HTML 5, Javascript, Jquery, and bootstrap. We accepted the challenge because the project is tiny and interesting, the point is, is possible to have 1 project that can be deployed to azure or IIS with no problem? and what kind of project should we create? I think that a simple asp.net project with some web methods and js will do the job, but I don't know if it will work on azure too. Back n 2010 I did something that way but now I am not sure it's still valid
Important: the web application should be able to query oracle on premise server, via web service but not sure if take azure service bus or azure vpn
It depends on how you build your application. I have built applications in the past that works both on-premise and on Azure. As long as you don't access any Azure specific features, there's no problem to deploying the web application project to an on-premise IIS.
If you use Azure-specific features or services from Azure, such as Azure SQL DB, you have to built an on-premise version. In my case it was simple as changing the connection string and the rest was done by Entity Framework, but you can use an IoC container, such as Unity, to change your implementation based on the environment you're running on. If the Azure environment is available (check through RoleEnvironment.IsAvailable) you resolve the Azure-specific implementation of some features and if not the on-premise implementation. In most cases that are just a few dependencies, for example if you use a worker role on Azure and a Windows Service on-premise.
I am building a set of services based on MVC 4. They should all be a part of the same authentication system. Currently I have got a separate project for all the model handling, including the Forms Authentication you get by default when making a new MVC 4 app.
Now, I would like to make a toolbar for logging in to our cloud services, and this toolbar must be made in such a way that it can be imported into our other services. Logging in with this toolbar should log you in to all our services, that are separated into different MVC apps. Thus logging in when browsing "service1" and then going to "service2", you should still be logged in with the same user.
Can anyone point me in the right direction here? Should I make a separate MVC app for this toolbar, and somehow reference it in all of my other projects? Should I export my controllers into a separate project and use them? I am not sure what the best practice is here, nor where to find the info I need on the matter.
Since you will be hosting your applications on different domains, you could implement some Single Sign On mechanism the way SO does it over the Stack Exchange network: https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work/64274#64274
Different domains means that you won't be able to share the Forms cookie. You should rather learn how to use one of the enterprise Single Sign-on protocols - using a recognized protocol means that you can easily integrate other applications, even if they are developed in different technologies (standarized protocols are supported by most development environments).
Possible candidates are:
the OAuth2 protocol. It is a respected protocol as Google, LiveID, Facebook, Twitter and others support it. To build an OAuth2 server you will need a framework like the DotNetOpenAuth.
WS-Federation. Got a lot of attention in .NET world as we got the Windows Identity Foundation framework which lets you create WS-Federation servers and clients.
Anyway, my advice is to invest your time now as this will pay off well in future.