I built a prototype I'm looking to deploy. It uses a database file MySite.mdf that I created. At some point in the process, the database file ASPNETDB.mdf was added to the project.
When I look at the web.config file, I see the connectionStrings tag but in there I only see the nested tag for MySite.
Now that I'm looking to deploy, what do I put for the second file in the tag.
Thanks.
You are using a SQL Server Express User Instance; if the server you are deploying to support this, then you won't need to change your connection string when you deploy.
The most common problem deploying a user instance database is that the server doesn't support user instances. (Note that user instances are only supported by SQL Server Express Edition). If the server doesn't support this configuration, you'll have to create a database on the server and change your connection string, a process that could involve quite a few steps.
If, on the other hand, your server supports users instances and it's using the same SQL Instance name that you are, e.g. SQLEXPRESS, the default instance name, you should be able to simply deploy your site and it will run (as long as you include the ASPNETDB.mdf file in the deployment).
Related
I have created an ASP.NET MVC web app which uses an SQLite database under EF6.
The app works fine in VS. The database is included in the project in the App_Data folder. When I publish to Azure (or an IIS test server on the LAN) I get an error. The Azure instance is showing an HTTP 500 error, and it only happens on views which require database access to load. Other than that it works fine. The IIS test server shows an error saying unable to open database file. I tried loosening file permissions on the .db file on the IIS instance, but nothing changed. I'm not sure how to go about doing anything on the Azure instance.
Can someone please assist me with debugging a SQLite connection problem on Azure/IIS?
Details
VS 2015 Enterprise
Azure app services (free tier, production server)
SQLite3 database
IIS on Windows Server 2012R2 (test server)
I have tried all sorts of combinations of connection strings:
setting a connection string to the D:/xxx/xxx path in Azure Portal
modifying the connection string in the deployment profile in VS (replaces value in web.config upon deployment)
just leaving it all the same
Nothing has worked or even changed the error. Perhaps one of those configurations is able to access the file but simply can't open it (which is sort of what the IIS error suggests, I think). Even then, how do I go about finding out?
EDIT
On the IIS test server I discovered that the entire problem was that the connection string in Web.config was wrong. I manually edited it on the server and it fired right up. I'm still not sure how to correct the path on the Azure server, nor how to correct my deployment settings in VS to inject the correct path. Thoughts along those lines are still appreciated.
EDIT 2
I've also found that each time I hit a page requiring DB access, I see this error show up in the application logs on Azure:
2017-01-03T20:25:32
System.ApplicationException: The trace listener AzureBlobTraceListener is disabled. ---> System.InvalidOperationException: The SAS URL for the cloud storage account is not specified. Use the environment variable 'DIAGNOSTICS_AZUREBLOBCONTAINERSASURL' to define it.
at Microsoft.WindowsAzure.WebSites.Diagnostics.AzureBlobTraceListener.RefreshConfig()
--- End of inner exception stack trace ---
After some abysmally slow debugging sessions, I finally remembered that in toying around I had set a connection string value in the Azure portal.
Apparently whatever value is set in the Azure Portal overrides (at runtime?) the values in the Web.config file
I simply deleted the connection string from the Azure Portal (your app/Application Settings/Connection Strings) and it worked. The final connection string looks like this:
<add name="yourThingEntities" connectionString="metadata=res://*/cadb_SQLite.csdl|res://*/cadb_SQLite.ssdl|res://*/cadb_SQLite.msl;provider=System.Data.SQLite.EF6;provider connection string="data source=D:\home\site\wwwroot\App_Data\yourSQLiteDBFile.db"" providerName="System.Data.EntityClient" />
To get the Web Deploy working in VS, you'll need to edit the publish profile to have a connection string matching the format
data source=D:\home\site\wwwroot\App_Data\yourSQLiteDBFile.db
Apparently not many people use SQLite for web apps, and most people should not. If you ever expect more than one user for your website at a time, you shouldn't fix SQLite, you should convert to SQL Server CE or just full-blown SQL Server which Azure will take care of for a paltry $5/mo. Choose wisely!
I have an ASP.NET MVC5 web application that was originally created using VS2013 and uses Entity Framework 6 Code First, with data migrations. It has been working fine (in production) for almost a year and has been re-deployed numerous times, from Visual Studio, using Web Deploy.
Today, I opened the solution in VS2015 and redeployed a known working version of the codebase to production without any problems. However, after deployment, the production website suffered from the problems described in this article, which I solved by applying author's the recommended fixes.
After applying these fixes, I now have a new problem: an exception that suggests that the application is trying to access the database using the wrong connection string:
Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed.
Within the details of the exception page, the cause of the problem is clarified:
The connection string specifies a local Sql Server Express instance using a database location within the application's App_Data directory.
I'm puzzled by this because the application has a dedicated SQL Server instance that is accessed using a regular connection string. I've checked the Web.config generated by Web Deploy and it seems to be intact. It contains a named connection string that correctly references the production SQL Server instance, and the code (which hasn't changed) correctly instantiates an Entity Framework ApplicationContext using the named connection string.
Does anyone have any idea why this application now expects to create its own SQL Server instance or what I can do to debug this problem?
Many thanks for your suggestions,
Tim
A few things you can try before making the web deploy:
Check if the project that contains the connection string declaration (web.config) is setted as the 'startup project'.
Rebuild the solution in release mode.
In the Publish Web wizard, in Settings, expand File Publishing Options and check 'Remove additional files at destination' and 'Exclude files from App_Data folder'
We have single lower environment server where we publish all our applications for Developer testing, pre-business testing etc. Problem we are facing here is all the developers changing settings in the config file for their convenience.
For example, development application should point development SQL db, but they are changing it to QA. and in some cases instead of publishing the application to staging they are changing QA connection strings to staging because publishing to staging requires extra effort (Merging the code to Main branch etc). No matter how many times we send email to development group they keep doing the same thing.
Is there a way to control web.config/app.config edit permissions and limit it to one person based on the application?
If SQL Server Connection String is the problem, you can use cliconfg.exe to set a specific ALIAS, in this case you must configure the alias on each server in your environment (development, test and production), with this, the connection string will always be "Data Source = SRVDBAPP" on the web. config / app.config.
Internally each client SQL Server will redirect to the corresponding database.
My requirement is to deploy an ASP.NET application in which I have a core library class project, service layer and a UI layer, using SQL Server database as backend.
My client needs to deploy it using some MSI or EXE, in which he / she should able to customize the installation to IIS and his SQL Server.
What I want to say, when I execute the EXE, it will ask me the basic requirement for the IIS like server name, virtual directory name, app pool etc , then automatically deploy it there. Now it should also ask the same for SQL Server database installation like server name, authentication, database name and so on....
I have tried but I can manage to deploy ASP.NET app not able to customize the SQL Server installation.
Also tell a feasible solution, as my database size is around 6GB. What will be optimized way to create a installer for that?
I once had to do something similar but my database was much smaller.
I scripted out my database into T-SQL statements for its creation from scratch and stored those in a text file.
I then wrote a .NET windows app that would prompt the user for SQL Server network location and credential information. This .NET application had the database creation SQL text file included in the executable as a resource file, and would connect to the specified SQL Server and execute the commands in the text file one by one. I was able to read the text file and parse commands out by delimiting on the keyword "GO"(linebreak).
Should the ASPNETDB be left in default app folder created by Visual Studio when deploying on webserver? I have another DB that is in the mssql data folder, should that be placed in same directory as well? Im not clear on whether it matters one way or the other.
It depends what environment you are deploying your application to. Specifically, what database servers are available to you or what you are able to deploy.
If you have, or can install, SQL Server and have full administration rights over the instance then the easiest option is to attach both databases to that instance and change your connection strings appropriately. In this case both files should reside outside wwwroot, in a SQL Server specific directory.
I presume this is how the database in your 'mssql' data folder is being accessed. The connection string SHOULD NOT contain 'AttachDbFilename'.
The other option involves SQL Server Express Edition and User Instances. User Instances are created on demand to host a database when the application user does not have the right to attach it to a setup created instance. User Instances run in the context of the application user, ASPNET in your case, and lack advanced security features.
Visual Studio uses this same setup. ASPNETDB is likely using this method. The connection string SHOULD contain 'AttachDbFilename'.
A database that has been created in a user instance can be migrated to a setup instance. However, a database from a setup instance cannot be attached to a user instance because the security information is unavailable.
See Configuring ASP.NET 2.0 Application Services to use SQL Server 2000 or SQL Server 2005 and SQL Server 2005 Express Edition User Instances for further information.