I've been trying to publish my application so I can install it on other computers but I always end up with an "SqlException" when trying it on the VS editor and when running it on the other computer
to make things clear I made the database using SqlServer and I attach it to the VS editor until now everything is going well and the application is running on the editor without any exceptions
but to make the application working on another computer I needed to copy the (mdf file from the SqlServer directory and paste it in the |datadirectory| of the project ) and of course I changed the connectionString dataSource to point to the mdf file and here where the exceptions begin to rise
The message of the exception says:
An attempt to attach an auto-named database for file
C:\Users\xXx\Desktop\Projects\Master Maint\Master
Maint\bin\Debug\GMAO.mdf failed. A database with the same name exists,
or specified file cannot be opened, or it is located on UNC share.
when I add the Initial Catalog=test in the connection string the exception message becomes:
"Cannot attach the file 'C:\Users\xXx\Desktop\Projects\Master
Maint\Master Maint\bin\Debug\GMAO.mdf' as database 'test'."
PS 1: It's not a permission issue cause I gave full access to the file from the advanced installer
PS 2: if there is the other way to run the database application on the other computer, I'm listening.
<connectionStrings>
<add name="connString2" connectionString="Data Source=(localdb)\v11.0;AttachDbFilename=|DataDirectory|\GMAO.mdf ;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
Thank you all , I'm not gone delete the question cause may others need it , but finally I found the answer
1 - the first bug was because the database file is not Categorized and that was solved by adding the Initial Catalog=test
2 - second the database file is named same us the the real database used in the project and that was solved by renaming the file
3 - third the log file that responsible of creating the database was not attached and that solved by adding the log file to the directory
Related
In my C# windows app using sqlite database, i observed each time i run the application and insert new records into the database, the records will be saved as long as the application is still running, but when i stopped the application, the records will be wiped out(deleted) from the database while using this connection string:
<add name="PITADatabaseConnectionString" connectionString="Data Source=|DataDirectory|\App_Data\PITApplication.SQLite3Db; Version=3;" providerName="System.Data.Sqlite" />
When i change the connection string to:
<add name="PITADatabaseConnectionString" connectionString="Data Source=C:\SqLite\Gui\SQLiteStudio\PITApplication.SQLite3Db; Version=3;"
providerName="System.Data.Sqlite" />
and save new records, it will be saved permanently and not deleted. I don't know what the issue is, i added the database to a folder in my application through add new items context menu, after adding the database to my application i set Build Action property to Content, and Copy to output directory property to Copy always.
i will appreciate your kind assistance.
I was able to resolve this issue by going to application properties window, under settings i added a connection string that points to the connection string in the app.config file. I also set the copy to output directory property of the database to copy if newer, and the issue was resolved, thanks to everyone that contributed.
TFS 2015, vNext build process (not xaml)
I'm trying to automate the deployment process for an MVC web app. The servers that it would be deploying to have different SQL connection strings. So my current deployment is to copy the web.config file to web.config.save manually, deploy the new version using WebDeploy then go to the old web.config.save file and copy over the connection string. I'm to the size now where this is not going to be sustainable much longer. So I need to automate this process further. I've got TFS automatically building and deploying to my test server (which also has a different connection string so it's a great test). In the "publish" properties, I tried deselecting the "Use This connection string at runtime (update destination web.config)" checkbox in the publish-settings-database section then checked in the project again to TFS. But when deployed, the web.config took the default setting. I don't want to remove this setting because I want a default connection string there for new installs.
I could write an xml transfer program to save off the current connection string then overwrite when complete again. But I figured there must be a way to do this with the current tool set and why try reinventing the wheel?
I started down the path to use transforms. So I created a web.config.release in VS2015 then added in this into the web.config.release file:
<connectionStrings>
<add xdt:Transform="InsertIfMissing" xdt:Locator="Match(name)" name="AppEntities" connectionString="metadata=res://*/Models.DBName.csdl|res://*/Models.DBName.ssdl|res://*/Models.DBName.msl;provider=System.Data.SqlClient;provider connection string="data source=.\SQLExpress;initial catalog=DBName;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
So, does anyone know how I can make the SQL connection string update only if it doesn't exist in the current web.config for deployment?
I got this experience with TFS 2015 vNext build,
in the 2Q of 2016 we assigned a Dev Ops person, who was really good with PowerShell, and he took ownership of the build and deploy process. Some of the things he came up with was a post build script.
Now to answer your question: For us, the Post-Build script would do the deployment part, and as part of the deployment you would update the connection string in the web.config. Now this would require someone in your team to become really good with PowerShell.
Now what I would do is write a special word in the original file like "{ConStringHere}", and the replace it with the Powershell script, that way you'll only replace it once.
See this how to verify if a file contains a word and replace it using PowerShell:
Powershell, using contains to check if files contain a certain word
I'll highlight some of the benefits we have encountered with this approach:
You don't need a solution, project and classes to modify some files. Most post-build files modifications can be done in powershell with line or 2.
You can keep the powershell scripts in TFS keeping a history and comments of the changes.
You can have the special values (Connection Strings, users, passwords) defined as build variables that are easier to change and with higher security than hardcoded values in a project.
You can have multiple scripts per environment. Ideally all scripts should be almost the same per environment, but maybe in production you are publishing to 2 different servers, so you'll need to call a line twice.
You'll save developers time, since the person maintaining the powershell doesn't have to be a full stack developer.
Note: This is different from Cant find my EF code first database
He didn't specify the initialCatalog while I did as you will see:
I have 3 CodeFirst DBs that I work with.
1 I create and use in my visual studio project when I hit F5
1 I host in Azure with test users. If I want to update it, I simply remove it and recreate it by publishing my VS project
1 that is somewhere in my localDB, hosting it in my IIS in my machine, which is my issue. I can't find it! I don't know where CodeFirst places it. But I can access the website which somewhat brings records from it! Please help me find it.
Here is my entire setup: in my publishing profile for the Local:
lets call the blacked out "ProjAPIContext"
and in my IIS
and the www root folder is simple. The AppData folder is always empty:
and I have this in my web.config
<connectionStrings>
<add name="ProjAPIContext" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=ProjAPIContext; Integrated Security=True; MultipleActiveResultSets=True; AttachDbFilename=|DataDirectory|ProjAPIContext.mdf" providerName="System.Data.SqlClient" />
</connectionStrings>
the context matches what is in code:
internal sealed class Configuration : DbMigrationsConfiguration<ProjAPI.Models.ProjAPIContext>
That's my setup. I am looking for the DB so I can navigated through table rows and run sql queries against it, etc...
I have looked my entire harddrive with that ProjAPIContext. I see other DB created with the same times frame like tempdb and masterdb but they can't be those.
I have attach the debugger to connect to my server code in my visual studio, but nothing hit. I've run the profiler in my sql, it doesn't print the connection string. It prints useless junk.
UPDATE #1:
I also looked here:
Update#2:
of course I've looked there:
Where else should I look!?
I have a major, two day head damaging question. I have a localDB for a desktop application coded in C#. The .mdf database file resides in the root directory for the application. When debugging in development this worked fine (using EF6). My connection string is as follows:
(LocalDB)\v11.0;attachdbfilename=|DataDirectory|\LocalStorage.mdf;integrated security=True;connect timeout=30
Yet when i build an installer and point my application as the 'Project Output' something happens whereby I receive the error upon successful install...
An attempt to attach an auto-named database for file C:\Program Files\Company Name\Program\LocalStorage.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
It seems my database does not install to the location (it simply isnt there). I suspect the '|DataDirectory|' in conn string does not point to an internal.exe location? Help Please, im at my wits end.
Most cases like this are dealt with by having a dialog in the application that describes things about the database. That includes the security connection (Windows Integration or not) and perhaps the db name and location. I'd ask about that in a SQL forum rather than an installation forum. Although some installs sometimes ask users for that kind of thing in a dialog, most users would rather get the install finished and then worry about the configuration.
I successfully followed the contoso university tutorial, getting it to work with SQL Express in VS 2010 - creating the DB in the App_Data folder. The tutorial follows the EF Code First model. Wanting to see the data in the tables, I opened the database in Server Explorer and was able to view the table data.
Now when I run it again, I can no longer access the database - the error given is:
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
Cannot open database "SchoolDB" requested by the login. The login failed.
Login failed for user 'DEV\bwilliams'.
Log file 'C:\ContosoUniversity\ContosoUniversity\ContosoUniversity\App_Data\SchoolDB.ldf' does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
DEV\bwilliams would be windows authentication.
Here is my connection string:
<add name="SchoolContext"
connectionString="data source=.\SQLEXPRESS;Initial Catalog=SchoolDB;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|SchoolDB.mdf;User Instance=true"
providerName="System.Data.SqlClient" />
I tried to open the DB again in server explorer and it tells me that the login failed. So I figured I could drop the database and have EF recreate it - but after doing so, I still receive the same error. The whole point is to create a project and deploy to an actual server, but I can't seem to get past these connection issues.
Update: Changing the name of the database in the connection string creates the new database and all is well. However, opening it up in Server Explorer in VS 2010 causes the same problem. Very frustrating.