I have a site that's running off windows azure and I have hooked up the database via a linked resource and it looks like the site should be using the database. I've also included the proper connection string in my web.config file.
When I run the website locally and use the azure database's connection string for my default connection, everything works and I've seen that updating data from my local machine is reflected in the remote database.
Whenever I try to access any page that makes database hits (ie, logging in or looking at the basic index (from scaffolded out views)), I get a 500 error. I tried turning on custom errors but the 500 error is all I get. I tried to debug it from my local machine but that didn't help at all since everything worked properly when running the site locally and connecting with the azure database.
I have also pulled down the web.config files and the web.configs on both sides are identical.
I figure that this has to do with a configuration issue, but I'm not sure what.
Is there maybe something I'd have to do with asp.net mvc 5 to make it work with windows azure? It looks like the .net framework is properly set on azure to .net 4.5. I'm guessing it has something to do with the fact that Azure just doesn't know it should be using the database supplied in the web.config.
Here are the web.config connection strings:
<add name="DefaultConnection" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnectionDeploy" connectionString="Data Source=####.database.windows.net;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnection_DatabasePublish" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
Windows Azure makes use of transforms to manage connection strings. The connection strings are merged in at runtime, and can be controlled from the configure tab on the Web Site management page. whenever you set up an Azure Database as a linked resource, it automatically configures the Azure Database server with firewall rules to allow connection from the web server, and adds a connection string. By using this connection string, naming it the same as the string used in development, it is not necessary to modify any code prior to deployment. If you don't set the Azure Database up as a linked resource, it is necessary to modify the firewall rules by hand, which doesn't play nicely with the scalability of Azure Websites, so it's not recommended.
As per Andrew-counts' suggestion, I went and checked out my EF migrations (after pulling down the Azure web.config file using the "Replace web.config from server" option so that I had the exact copy that the server is using. I then enabled custom errors. It turns out that the pages were failing to load because of an error that stated that the table dbo.AspNetRoles already exists.
It appeared as though it was trying to run the EF migrations despite the fact that the tables already existed. To remedy this, I decided to go and wipe out my current database (I had just setup the database today so no harm doing that) and then, from the package console in visual studio, ran the Update-Database script before deploying anything to the server. When I did that, it correctly added the records inside of the dbo.__MigrationHistory table. I then checked in my changes so that the visualstudio.com build I have connected to my solution would build and deploy to Azure. The problem persisted, but what I realized was that I need to disable the automatic build + deploy that I was using and instead use the right click + publish, since doing it from the visual studio build wasn't connecting to the azure database properly (it wasn't transforming the web.config). When I used the publish from within visual studio, the site worked like a charm.
Thank you for all your help
Related
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 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'm developing an ASP.NET web app that needs to access an SQL Server database. The server the app needs to run on is running Windows Server 2000, SQL server 2000, IIS6, and .NET 2.0.
If I run the web app on my machine with Visual Web Developer 2010 with the testing webserver in Visual studio, but accessing the database on the actual web server, it works fine. However, If I put this app on the actual webserver, and try to access it through the browser, I get a permissions errors saying I don't have access to those tables.
There are two tables my app needs to access. On one of them I changed the permissions with SQL Management Studio to allow the public group select permissions, and that solved the problem. On the other table (very large table) I tried to do the same, but got an error saying it timed out waiting to get a lock on the table. Is there a way to change this timeout or another way to change the permissions?
I don't believe I should even have to change the permissions though, because there are classic ASP apps on that server that access the very same tables. I think the issue is the user that is being used to access the tables. If I can access the tables running the web app from my machine, and classic ASP apps on the server can access them, but my ASP.NET app can't, my ASP.NET app must be using a different user account. How can I check this and make the necessary changes?
Regarding your permission error, it's probably because on your machine the app is accessing the database with your permissions, with windows integrated login.
Normally, a web application is supposed to access a database using a technical user, that is specified in the web.config file, in the connection strings section. It's something like
<configuration>
<connectionStrings>
<add name="myConnsStr" connectionString="server=myserver.example.com;database=mydatabase;uid=tech_account;pwd=tech_account_password" providerName="System.Data.SqlClient" />
</connectionStrings>
...
</configuration>
How does yours look like?
For the other one, yes, do the permission change in T-SQL. If you are not sure how to do that, do the change in the designer, then before clicking OK, use the Script button in the header area. Script the change to the clipboard and then try to run in a new query window. You can play with the query timeouts in the options dialog.
You could try setting the lock timeout to -1 (meaning it'll never timeout)
SET LOCK_TIMEOUT -1
GO
And you can also try adding the permissions using a query
sp_addrolemember #rolename = 'db_datareader', #membername = 'YourAspApp'
You can also try to change your asp.net user in the asp.net connection string to a user which already has selecting privileges.
Let me know if any of that worked, it's a good place to start with =)
I have uploaded my database backup and it works fine. but since I've created a new user from ASP.NET Configuration I've that it saves the user information in the ASPNETDB.
I already published my database from MVS and open it in M SQL Server Management Studio 2008 to create the backup but I haven't find the ASPNETDB in it.
my question is:
doesn't this database just upload it automatically when I upload my database? coz when I publish my website it doesn't appear.
if not, How can I upload ASPNETDB so I can login to my site because I'm using authorization to this user ?
Ok im gonna make a few assumptions here and explain them because this could be many things:
Assumption 1 (connection string issue). the user credentials for a database running on your local sql server are likely to be valid on the server on which you deploy to (seems to be the way of the world) try connecting to the remote database using the credentials in the remote "published" copy of the websites configuration file. (connection string)
Assumption 2 (publish settings not correct). when you use the "publish" option from within visual studio you only deploy the website to my knowledge but some say you can configure it to deploy the database as well.
I would suggest making a change (eg add a table to the aspnet database) on your dev machine then using publish to see if that new table appears on the remote server, if it doesn't go to the server explorer in visual studio and run the wizard by right clicking on your database and clicking on "publish to provider" i tend to push the entire db to a script file then manually run that on the remote database (seems the cleanest option).
Assumption 3 (does the database even exist on the server). I could be wrong here but from what you're saying it sounds like you published the application and not the database to the server ... that results in some nice yellow server errors.
Check that the database exists if not ... do as suggested in asumption 2 and push the database manually.
I suppose you're using the Membership API.
If you are using ASP.NET on a machine with SQL Server Express Edition, the required by Membership API underlying data store is created automatically for you when you create the first user. This functionality is provided through the SqlMembershipProvider. The SqlMembershipProvider automatically creates a new database in the website’s App_Data special directory called ASPNETDB.MDB. This database implements the complete schema, which is necessary for storing and managing user information, role information, user-role assignments etc.
You can easily check it. In your web.config you should see something like:
<connectionStrings>
<add name="ApplicationServices" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
So this database should have been uploaded along with your web site.
Please consider this tutorial if you want to create aspnetdb or necessary tables in your own database (which is a good praxis).
May be you will be also interested in the similar discussion here. Besides if you still want to get this .mdf database in SQL Server Management Studio you can learn how to attach a database here.
I been trying to get my Visual Studio 2008 to run my Web Application on IIS7 on my Windows 7 machine but I just can't get it to work. I'm using the SQLEXPRESS I been following this Tutorial, but I get the following error message.
"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."
my connectionString seem to be ok
<add name="testConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|test.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
The site run with out database connection.
Any ideas and thoughts about this?
Thanks guys
Make sure the instance name is called "SQLEXPRESS" exactly.
Make sure the "test.mdf" file exists in the "App_Data" folder.
When you are adding the DB using Server Explorer, use "Test Connection" first.
In IIS7,
they use default asp.net database.
create a new application pool instead of using default.
and keep your database in that.
go to sql configuration manager and in the properties,select local system instead of build in system.
Now,it may work.