In a C# 2010 application, I used linq to sql to setup my database connections.
Now when I move the application to a different database, the original database is still being used. Basically the connection string is hard coded into theapplication.
I tried to follow the linq listed below, but everything did not work.
The part that says, "1.Open up the LINQ to SQL designer, and open the Properties tab of the designer (the schema itself),
expand Connection and set Application Settings to False. ", I did not see this option.
The closest thing I found was connection and I set that value.
Here is the way the code looks now in the *designer.cs file.
publicpartialclass eDataContext : System.Data.Linq.DataContext
privatestatic System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource();
#region Extensibility Method Definitions
partialvoid Inserte_Detail(e_Detail instance);
partialvoid Updatee_Detail(e_Detail instance);
partialvoid Deletee_Detail(e_Detail instance);
partialvoid InsertIBook(IBook instance);
partialvoid UpdateIBook(IBook instance);
partialvoid DeleteIBook(IBook instance);
partialvoid InsertIPackage(IPackage instance);
partialvoid UpdateIPackage(IPackage instance);
partialvoid DeleteIPackage(IPackage instance);
partialvoid UpdateIError_Tran(IError_Tran instance);
partialvoid DeleteIError_Tran(IError_Tran instance);
partialvoid InsertTransaction_Type(Transaction_Type instance);
partialvoid UpdateTransaction_Type(Transaction_Type instance);
partialvoid DeleteTransaction_Type(Transaction_Type instance);
partialvoid Inserte_Tracking(e_Tracking instance);
partialvoid Updatee_Tracking(e_Tracking instance);
partialvoid Deletee_Tracking(e_Tracking instance);
public eDataContext() :
public eDataContext(string connection) :
public eDataContext(System.Data.IDbConnection connection) :
public eDataContext(string connection, System.Data.Linq.Mapping.MappingSource mappingSource) :
public eDataContext(System.Data.IDbConnection connection, System.Data.Linq.Mapping.MappingSource mappingSource) :
Here is what the app.config file looks like right now:
<?xml version="1.0" encoding="utf-8" ?>
Can you tell me or show me in code how to fix my problem so the application does not
use the hard-coded values that were setup by linq to sql?
I don't use Linq to SQL but we have different config files for each environment. The UAT config file will have a different connection string pointing to the UAT server, when you compile for deployment you chose the config you want to use and make sure the config file has the correct connection string.
Never underestimate the power of human stupidity
You are correct that each database has a different connection. However in code, can you show me how to change the connection string and how to change the app.config file to point to the different databases?
The way that linq to sql works is it hard codes the connection string. I want avoid this hardcoded connection string.
Err...That is your connection string. It is in your app.config.
So if you want it to point to a different database then you change that.
If however that is not where your connection string is coming from then it is certainly coming from somewhere so use a text editor to search ALL files you in your source tree for the connection information.
First of all I have average experience with .Net programming, so please go easy on me .
I have an windows application project that consists of 10 Forms. At the moment when I compile my app, it generates a single Exe file. Everything works good.
I want to write an update program for my application, and also after reading some best practices on how to build your app i realized I also need a lot of code rewriting in order to make my app look good.
The thing is I am thinking it would be better to split each form into a separate DLL file, this way achieving some form of modular structure and make my app easier to manage and update.
The problem is I don't have enough experience to know whether splitting each Form into a separate DLL is a good idea or a bad idea, so I'm asking you guys to tell me, from your experience, how would you structure such a project and what would the expected files be ?.
Thank you for your time, and I hope I made myself understood.
In general, you won't see any benefit from splitting the forms out into separate DLLs. When you read about modularisation, people tend to be talking about splitting out application logic, rather than the presentation tier. So, you can split out the actual logic, which is fine, but you should leave the forms where they are.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
I will give this some more though. Each form I have is part of a module of the application logic.
So I thought it would be recommended to split them into DLL's or more experienced programmers would split the forms at presentation level too.
Maybe I will just leave it as it is, because it is working fine so far and I will write an update program that overwrites the entire exe file instead of particular DLL files.
10 forms is fairly small as apps go, I'd leave it in the single exe. It is usual to divorce the UI from the business logic and the database functions. I'd assume that all your business logic is in the code behind the form, this is usually extracted into a separate class.
Never underestimate the power of human stupidity