I use code first and the app works well on a local database which was generated.
But when I deploy to Azure, although it succeeds, the tables are not created, just the empty database.
I excluded the local app_data folder and chose to run code first migrations
in the deployment options.
Any tips what's wrong?
Have you configured Azure deployment to replace connection strings (via the publishing wizard) or are you using environmental variables in your code? It doesn't sound like it. It sounds like you deployed with localdb which does not work in Azure.
You need to either (there are more options, but these are easy to implement):
Configure your deployment process to update your web.config with your SQL Azure connection string (you can use config transformations or deplyment wizard)
Use Azure environmental variables to be used automatically when running in Azure and local variables when locally
Related
I've got a blazor server and client side application that is deployed into a docker container. I have multiple appsettings.json files. Each file should be deployed with its corresponding environment
I've seen some discussions which assert that the ASPNETCORE_ENVIRONMENT needs to be set for the server side application, which would automatically set the same value for the client side application. I've tried this. However, it seems that for the dev environment example, the appsettings.json file is still being used. I get a sign in error on the deployed dev environment which indicates that it's still using the appsettings.json file.
thanks
This was happening because we incorrectly set the ASPNETCORE_ENVIRONMENT correctly in the server application. Once we did that, it worked.
I have created a simple ASP.NET Core MVC application using EF Core and SQL Server. On the Windows development machine it is using localdb. I am trying to deploy to Azure App Service (Linux). I have created an Azure SQL database. Deploying from Visual Studio 2019, I have set the database as a dependency. In the publish profile settings I have selected the Azure SQL connection string for the database context I am using. I have also checked the EF Migrations and on deployment the script successfully created the tables for the application. I can connect to Azure SQL and see the tables. However when I run the deployed application and try a database operation I get: PlatformNotSupportedException: LocalDB is not supported on this platform
I can see from the docs various ways to set the connection string but I would like to know what the publish wizard in Visual Studio 2019 is trying to do and why it is not working? I'm also unclear where the password is stored. In the publish profile the password seems to be in the connection string as plain text, not good. I'd like to know how to get this right for production.
Update I have fixed this for the moment by following the steps in the Linux tutorial, using the Azure CLI and running the following command:
az webapp config connection-string set --resource-group [myResourceGroup] --name [app name] --settings MyDbConnection='[connection-string]' --connection-string-type SQLServer
I am not sure of the security of this approach and plan to investigate further.
The publish wizard simply handles the database creation/migration for you, it doesn't modify your project, as that's 1) not its purpose and 2) it can't make the configuration decision for you (i.e. use appsettings, environment variables, etc.)
You need to provide the connection string in production via configuration, just as in development. Since you're deploying to an Azure App Service, the most logical place for that would be to the App Settings in the Azure. These will be loaded in via environment variables. Simply specify the same key you're using in development and specify the production database target there.
We have a solution consisting of several class libraries, and a Web
Application Project. We are using TFS 2012 with Team Build. The solution
compiles correctly on the build server.
I am currently trying to do this via MSBuild Arguments.
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=False /p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=https://testWebServer:8172/MsDeploy.axd?site=direct /p:AllowUntrustedCertificate=True
/p:DeployIisAppPath="direct"
/p:AuthType=NTLM
The solution builds but does not deploy. I get the following error message:
msdeploy error ERROR_DESTINATION_INVALID: Web deployment task failed.
( Could not connect to the remote computer ("https"). Make sure that
the remote computer name is correct and that you are able to connect
to that computer. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_INVALID.)
[C:\Builds\1\ProjectName\Solution General Build\Sources\Temp
Source\ProjectName\Solution\Project.csproj]
Is there another argument I should be passing to specify the server? I did
not intend for https to be the server name... I have tried omitting the
https:// to no avail, error is the same, so it is getting the value from
somewhere.
I have tried this with the following values for MsDeployServiceUrl:
https://testWebServer:8172/MsDeploy.axd?site=direct
https://testWebServer:8172/MsDeploy.axd
"https://testWebServer:8172/MsDeploy.axd?site=direct"
https://192.168.X.X:8172/MsDeploy.axd?site=direct
"https://192.168.X.X:8172/MsDeploy.axd?site=direct"
testWebServer:8172/MsDeploy.axd?site=direct
Update
Alright, the following is at least connecting:
/p:MsDeployServiceUrl=testWebServer
I have seen numerous posts concerning that particular argument, and almost invariably they are a URL, not just a hostname (the ones that appear to be a hostname I thought were just written that way for brevity).
I am now, however, faced with a new problem. I have made the Build Service Account (domain account) local admin on the webserver, and I am getting msdeploy error ERROR_USER_NOT_ADMIN as well as an Audit failure in the Security log.
Resolution
These are the MSBuild arguments I am currently going with.
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=False /p:MSDeployPublishMethod=WMSvc /p:MsDeployServiceUrl="https://SERVER:8172/MsDeploy.axd" /p:AllowUntrustedCertificate=True /p:DeployIisAppPath="siteName"
I am now getting ERROR_USER_UNAUTHORIZED. Apparently I have either not set up the delegation correctly or the IIS Manager User I have created is somehow incorrect. Regardless that will go in a different post if necessary.
What is the Server and IIS version, you are using?
IIS 6 uses Web Deployment Agent Service (MsDepSvc), whereas IIS 7 usually uses Web Management Service (WMSvc) which have different URLs (besides, you have to be an admin on the target server to execute MsDepSvc.
Can you try specifying
/P:MSDeployPublishMethod=WMSvc
Based on this article from Troy Hunt, Web Management Service (WMSvc) is using
.axd
URLs (the one you specify), whereas you are trying to force it use RemoteAgent publish method which seems to be inconsistent.
See this article for complete set of differencies between WMSvc and RemoteAgent publish methods.
I had a similar issue. To resolve the issue I tried the following steps:
As it was a hosted server we had to make sure that the port 8172 was open (obviously).
Creating a new login and set this up in IIS -> Deploy -> Configure -> Configure Web Deploy Publishing on the target server. I made sure that the password didn't have any spaces in to avoid the quotes issue just to be sure.
Actually running a manual deployment from the build server.
Finally specifying an IP address in the MSDeployServicerl:
/p:MsDeployServiceUrl=xxx.xxx.xxx.xxx:8172/msdeploy.axd
None of the web site names worked for me either. None of my parameters had quotes in. Of course if you leave a space in incorrectly in one of your parameters you will get the error:
MSBUILD : error MSB1008: Only one project can be specified
I am trying to deploy my ASP.NET MVC 3 application using Visual Studio 2010's "Publish Web" option (build/Publish App). This generates deployment/bin, deployment/scripts, deployment/views etc.
I loaded these resulting deployment files/folders to a web server running IIS 6. Afterwards, everything seemed to run just fine on this web server.
I then started to make new updates, just to my local environment. After doing that, the deployed version of the site stopped working. I looked at the stack trace and the web server seemed to be referencing controllers.cs from my local environment, as opposed to the dll's in the bin directory on the web server.
Is there something else I need to do before deployment to tell the web server to use it's own bin files as opposed to files on my development environment?
BTW both my development machine and the web server live on the same network.
Update:
Another thing that made me suspect that the web server was referencing my local dev environment was that when a new user tried to access the application she got an IOFileNotFoundException in regards to a reference to "Interop.ActiveDs.dll". The stack trace mentioned my_local_path/Interop.ActiveDs.dll. This file was in fact not on the web server so I added it and then her error went away. The Odd thing was that all other users before her did not recieve an error about this missing reference.
I want to run my application through azure project in Visual Studio. But it runs it not as I expected. It runs the project like: http://127.0.0.1:82/ not as I want: http://testproject.com.
If you are running the site on your local machine you can update your Hosts File so that it includes an entry for testproject.com that points to 127.0.0.1 while you're testing. When you're done testing make sure you remove the entry in this file.
Once you push it to the cloud you can use a dns cname to redirect your domain. Here's an article that explains it more http://blog.smarx.com/posts/custom-domain-names-in-windows-azure