How is it possible to deploy MVC3 web roles to windows Azure? Most of the tutorials seems done on deploying ASP.NET web roles than the MVC3 one.
can any one give me a link/hint?
Way back in the old days, MVC3 wasn't supported out-of-the-box because the appropriate DLLs needed to be manually added by you (or installed as a startup task). These days, the MVC dll's are all there using the MVC3 template, so there's no difference in what you'd need to do, between asp.net and asp.net mvc deployment. The basic Web Roles and Worker roles are just Windows 2008 Server VMs, and the deployment process is the same. The most important part, when starting out, is making sure your connection strings to storage point to "real" storage and not dev storage (such as your diagnostics connection string). Also, session state defaults to using SQLExpress, which isn't running in Windows Azure, so you'll need to either use a SQL Azure database (plus proper connection string) in web.config, or change session state to use Cache (again, a web.config change).
Related
I am totally new to Azure and have been asked to move websites to Azure hosting.
Moving to Azure hosting do seems to an issue but problem seems to be with the asp.net session state, our website which are developed using asp.net 4.0 & MVC & some of the website are quite old developed few years back around 2013-2014.
My big worry is how to choose session state or third part session cache where we wont need to make any change in code other than to web.config file.
We so many article around it has created confusion.
I would appreciate best way we can migrate to azure hosting without making changes to code other than web.config file.
I looked at Azure Redis Cache but this also required to install Microsoft ASP.NET Universal Providers and changes to config file link.
Does Azure provide MS SQL Database with build in support for SQL Session, so that we only need to make change to web.config file rather than installing packages using nuget etc..
This option of Microsoft blog seems to be the option can some config if this right & easy approach. but also at the comment user have posted few issue with this approach
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2017/11/28/asp-net-session-state-with-sql-server-in-memory-oltp/
Based on above let me give more details
We use windows based dedicated server for hosting
We use MS SQL SERVER Windows 2012 for database
IIS 7.5
and other software to managing website such as plesk
We have website developed in asp.net webform based website running with framework 4.0 or 4.5
We also have few asp.net MVC based website running on framework 4.5
We use InProc default session state
Firstly, my big concerns are session state, i want to migrate to Azure without making any changes to code except changes to web.config is this possible?
Second we use MS SQL SERVER 2012 as database what is equivalent of same in Azure as in some page it refers database as SQL Database and some where as Azure SQL Database which creates confusion of this SQL Database or Azure database as i have red that these are two different things?
Third, let us say i choose Meb+Mobile--> App Service Standard Package (which comes with upto 10 instance) what are these instance? and will individual session always connect to same instance?
Forth: Database i have about 20 database one of them is about 6GB & other database are about 200MB-700MB which service should i use for database
Single Database or Elastic?
Can i create multiple database under elastic mode?
Let us say if i choose "100 eDTUs: 10 GB included storage per pool, 200 DBs per pool, $0.20/hour" will i have total of 10GB space for all database in elastic pool and what is per pool and how many pools will i get in this option.
Fith:Disk Space, let us say i choose App Service "S2: 2 Cores(s), 3.5 GB RAM, 50 GB Storage, $0.200", is 50GB diskspace include OS or space allowcated to file which we upload?
I have asked too many question as i didnt had clarity from MS chat as they just passed links which can be confusing at time
Yeah, the Redis session state provider is a Nuget package, though you could possibly install it in another project and just throw the DLL in the app's bin folder. I have not tested this, so I can't know if it would actually work.
But another option for legacy apps is to keep ARR Affinity on in the App Service (if you are using them). This effectively sets a cookie on the client when they first connect so the load balancer will always connect them to the same instance, so in-memory session state works.
The problem with that is of course if the instance restarts for any reason, you lose the session state. Auto-scaling is also a bit of a problem.
I created a simple ASP.Net Core application with user authentication (so all the Entity Framework has been preloaded into the web app template). It is connecting to my database with the connectionString that is located in my appsettings.json file, with "data source = {computerName}\\{serverName}" setup.
The database instance and Visual Studio are located on the same machine. This works fine in returning data to the web api while within development and debugging mode. When I publish it and try to go to the site from a domain name it does allow me to view the webpages that are not needing database connection but the rest that need data from the database returns pages like this:
Error.
An error occurred while processing your request.
Development Mode
Swapping to Development environment will display more detailed information about the error that occurred.
Development environment should not be enabled in deployed
applications, as it can result in sensitive information from
exceptions being displayed to end users. For local debugging,
development environment can be enabled by setting the
ASPNETCORE_ENVIRONMENT environment variable to Development, and
restarting the application.
I have tried to change the Environment Variables for ASPNETCORE_ENVIRONMENT from Development to Production to no success.
I have tried adding appsettings.Production.json to publishOptions in my project.json file, even though there is no file appsettings.Production.json, and this did not help. dotnet publish
Adding the evironment variable in the web.config file did not work Deployment
I need help getting the published web api to connect to my SQL Server database from outside the development Visual Studio setup.
The last thing I can think of is that maybe I am incorrect in how I understand the connection string. If the web api uses the connection string to connect to the database from the server-side then it should work just fine like it does when in development calling to http://localhost:port# since it's all on the same machine. But, if the database string needs to be based on a client-side call then it would have to be with domain names and IP addresses.
Can someone tell me which one it is?
The only thing else that comes to mind is that there is something I am not doing, and need to do, inside of IIS Manager. I see connect string there as well but unsure what that is for our does since the connection string is inside the application. Also maybe I am suppose to give the app some kind of authorization to communicate with the database server even though they are on the same machine???
After much research, finally googling "how to deploy a web api in iis" I was able to learn from Host ASP.NET Web API in IIS using Visual Studio Publish that I needed to add the security entity BUILTIN\IIS_IUSRS. Then placing a mapping to my database tables and giving db_datareader (and possibly db_datawriter) for the database to the IUSER to allow access from my self hosted IIS web api. This from the above mentioned link with the part stating
Accessing Database under IIS APPPOOL\ASP.NET v4.0
As we are using ASP.NET v4.0 App Pool make sure IIS APPPOOL\ASP.NET v4.0 is added to your Database Server -> Security -> Logins.
I have two working servers (at different locations) with IIS hosting WCF. On each server, WCF (by way of an entity framework) connects to a PostgreSQL database on the same server. My development machine is my laptop.
I have added new stored procedures to the PostgreSQL databases and added these to the WCF implementation on my laptop.
Currently, the Server only has the production site set to use ASP.Net v4.0 application pool.
In Visual Studio 2010 (.Net 4.0), can someone please tell me how to:
Create a Web Deployment Application that will use the existing PostgreSQL database already on the Server (I do not want to export any database from my laptop).
Create a Web Deployment Application that will use the existing PostgreSQL database already on the Server, but target a non-production site like "TestingSite".
Is there anyway of creating a Web Deployment Application that will CREATE the new site, "TestingSite" on the Server with the correct settings.
Ultimately I'm hoping for something really simple that I can develop the WCF code I need on my laptop, then deploy it to the server for testing.
I want to try moving to VNext from Asp.Net MVC 3, I used windows service project (http://www.interworks.com/blogs/banderton/2009/10/30/long-running-tasks-aspnet) but this doesn't seem to work on VNext, because it doesn't have proper System.ServiceModel reference and I cant add dll.
Is there a way around? Would you recommend other ways to run long tasks such as big file import/calculations with VNext?
Generally, no - not because of any feature-set in ASP.NET vNext (it's been possible since .NET 1.0) but because of permissions: a process needs to run under a high-privilege security context or be able to impersonate such a user account in order to control Windows Services.
w3wp.exe (the application pool hosting process, and by extension, the application pool and the applications within it) all typically run under a least-privilege user-account (often NT AUTHORITY\NETWORK SERVICE or a custom user account with enough permissions to write to the website's root directory, a database server, and not much else (in recent versions of Windows this is further reduced to the concept of a "service account" which your worker-process and pools run under).
The easiest solution is to create a user-account with the necessary privileges to control services and run your application pool process under this user-account, but I don't recommend this.
Consider, instead, creating a new Windows Service that then controls the other service (or if it's your own service, do it in-proc) that uses some form of IPC to communicate with your ASP.NET application to shut itself down and perform other tasks. You might want to look at named-pipes, for example.
If you need to run ASP.NET in a Windows service, you can do it now using ASP.NET 5. I wrote a detailed post on how to do this here: http://taskmatics.com/blog/host-asp-net-in-a-windows-service/
I'm upgrading an ASP.NET 4.0 app from:
Windows Server 2003 and IIS 6
to:
Windows Server 2008 and IIS 7.5
This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.
Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.
ApplicationPoolIdentity
Create your own service account on the domain
SQL authentication
Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.
User ASP.NET Runs Under
Assign Permissions to ApplicationPoolIdentity Account
I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).
As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.