I am writing a C# .NET 4.5-based Windows Forms application.
I'd like to set a flag (Boolean) in one of the classes (probably the main Form's class) that defines whether the app is running in Production of Debug mode. I will use this flag to control various actions of the app, including GUI-based actions as well as which connection string to use.
I don't have a problem with the GUI-based stuff because the flag is defined in the main Form's class, but I'm having a problem with the connection string. There is a separate class for DB access, which basically just defines a constant like this:
namespace MyApp
{
class DatabaseInterface
{
public static string MyConnectionString = "Data Source=server;Initial Catalog=db";
}
}
I'd like to change the connection string (really just the "server") depending on that production/debug flag. I do NOT want to put an if/then/else in every place where the connection string is used (to toggle between debug and production strings), but would like a single named connection string that can be used throughout the app. I'd also prefer to NOT have to instantiate a DatabaseInterface object (I know I could dynamically change this in the "get" definition of a public property of the DatabaseInterface class).
Is there a way to do this?
If you want to do this based on a flag and don't want the if everywhere, I'd suggest that you use a simple getter like this :
namespace MyApp
{
class DatabaseInterface
{
public static string getConnectionString()
{
return myFlag ? "Data Source=server;Initial Catalog=db" : "AnotherString";
}
}
}
Related
I am a total beginner in C# programming language. I am trying to use Getter and Setter in order to set the string in ProjectA and the retrieve it in Project B.
Project B uses Windows Forms, and I wasnt to set the value of TextBox
with the retrieved string.
Project A is a Console Project and it just reads out some stuff from
file and stores it in string, which I want to retrieve.
However, this is my call in Project B:
string cardOwner = Transmit.Program.CardOwner;
Debug.WriteLine("Card owner = " + cardOwner);
tb_cardholder.Text = cardOwner;
And this is my Getter / Setter in Project A:
private static string _cardOwner;
public static string CardOwner
{
get
{
return _cardOwner;
}
set
{
_cardOwner = value;
}
}
_cardOwner = System.Text.Encoding.ASCII.GetString(bCardOwner);
But in Project B I get "" empty string.
I have included Project A in Project B (added Reference and wrote "using ProjectA").
Any ideas what's going wrong?
Thanks.
Just because you include a project and use its classes in your project B, it doesn't mean that you also use the instances of these classes.
Take the following class:
public class Test
{
public string Message { get; set; }
}
You can put this class into a DLL project (Tools) and reference it from other projects, like a WinForms project ProjectA and a console project ProjectB.
In both projects, you can write something like:
Test t = new Test() { Message = "Hello" };
That creates a new instance of the Test class, but the two running applications ProjectA and ProjectB do not exchange the data! They are completely separated.
The same is true for class properties.
You can't share information between two different applications so easily. Static properties only share data within the same Application Domain, that is in most simple constellations within the same Windows process.
If you want to transfer data between two different processes, you need to use an explicit mechanism for interprocess communication.
When is this line executed?
_cardOwner = System.Text.Encoding.ASCII.GetString(bCardOwner);
You'll need to put that in a method and call that method (and knowing when the call happens will help you understand why _cardOwner is not set:
public static void Init()
{
_cardOwner = System.Text.Encoding.ASCII.GetString(bCardOwner);
}
Then call this method somewhere that you know will be executed before you need _cardOwner:
Transmit.Program.Init();
string cardOwner = Transmit.Program.CardOwner;
tb_cardholder.Text = cardOwner;
I am working on a windows service in c#, and perhaps I might use the same methods in my web application if it works. The main service is using a sqlconnection that is used for itself, retrieved from app.config using ConfigurationManager, and it creates a few threads of different types, to run several tasks. Each of these threads has its own connection (stored in class property).
public partial class MainService : ServiceBase{
private static string SQLConnStr;
protected static SqlConnection SQLConn;
}
class OtherClass{
private sqlconnection sqlconn;
private string connstr;
}
The part that I am stuck with, is that, when I create another object type, I need that object to be able to access the DB using OtherClass' connection. This new object is created and called in OtherClass for processing later on.
Is it possible to re-use the sql connection from OtherClass?
Is it safe and secure to make the sql connection string as public static?
Is the design I am using not good?
pass it to OtherClass constructor ?
details with example:
public partial class MainService : ServiceBase{
private string SQLConnStr;
}
class OtherClass{
private string connstr;
public OtherClass(string _connstr) { this.connstr = _connstr; }
public foo() { using(var conn = new SqlConnection(connstr) { ... } }
}
Creating new SqlConnection each time is fine in .NET since there is connection pool.
You should use the respective configuration mechanism. For applications/windows services this would bee the app.config file, for web applications it would be the web.config file and for DLLs, the settings should be copied from the DLL's app.config to the application's app.config/web.config as described here many times (DLLs don't read their config files, so the settings need to go into the application's config file).
That being said: Use the settings designer in Visual Studio to simply add a new connection string setting. If necessary, add it to other projects, too.
To use the connection string from class within the same project, you can then simply use Settings.Default.MyConnectionString assuming that the setting is named MyConnectionString.
Another exception for DLLs: Some DLLs don't need their own settings, but they need to access a database. In that case you could pass the connection string or even an SqlConnection to the function that requires database access.
There is a distinction between connection*string* and the connection itself. For the connectionstring (describing where you should connect to), you can store that in a config file so youu can easily change it.
The connection itself that is used to communicate with the database must be opened and closed. When you use datareaders, you can't usually use the same connection for simultaneous commands.
It is best to open a new connection as late as possible and close it as soon as possible. Let the built-in connectionpooling do it's thing to optimize the real connections.
I like your answers, but mine is the case of bad design, after looking into it a while. So I decided to create a public static query function in the MainService:
public static void qQuery(string querystr){
using(sqlconnection conn = new sqlconnection(sqlconnstr){
.....
}
}
sqlconnstr is a private string in MainService which is initialized when the service starts.
I hope it is safe and secure way of doing it...
I am using several class libraries within a project, and one of them is a typical "project.common.dll" library containing some common helper functions. One of these functions is a debug function that creates debug output.
Now I would like to enable/disable debug output by using a user-level property (application settings). How can I reference variables defined in main application's program.cs within this class library ?
Update : Thanks all. I will probably create a static method in my base application that performs the check (to debug or not) and then calls the Debug function in the common library.
You can't.
What you will need to do is have the properties in the class library itself and when you create the instance of it in your main application pass the user setting in:
var debug = new DebugInstance { Output = this.Output };
or set the parameters if it's a static class:
StaticDebug.Output = this.Output;
You can use the ConditionalAtrribute:
[Conditional("DEBUG")]
public static void WriteDebugInfo()
{
Trace.WriteLine("what ever...")
}
This way when you build in Debug mode, the method is invoked; in Release mode not.
Use parameters on the constructor of the Debug class (or a static constructor if the class is static).
I have a WinForm project that contains several UserControls. This WinForm project has a reference to an assembly (lets call it lib.dll) that is created from another project (Class Library) that exists in a different solution.
Now, several of the UserControls make calls into lib.dll that return values from the app.config file. At runtime lib.dll works fine and returns the necessary data but at design time, I am getting an exception from lib.dll because the app.config sections are NULL (the exceptions are by design).
Now I could go through each control and wrap any code that calls into lib with
if(!DesignMode) { //code }
But that is a lot of controls to go and apply that to. Is there something I can do globally that would be more elegant then testing the DesignMode property?
Edit
In response to the two comments left below: the solutions provided don't appear to work. The assembly that is causing me a problem lives in the same directory as the app.config. The general directory structure looks like this
References Folder
Configurations (Folder)
appsettings.config
app.config
lib.dll
app.config pulls in several other config files (appsettings, cnx strings, etc) which reside in the Configurations directory. In the case of my exception the value I am trying to get resides in one of these ancillary config files that is referenced by app.config.
This is an interesting question. A solution could be to create in lib.dll a static class like this one :
public static class Config
{
private static readonly _param1;
static Config()
{
_param1 = ConfigurationManager.AppSettings["Param1"] ?? "Your default value";
}
public static string Param1
{
get { return _param1; }
}
}
Then, in your code, insted of writing ConfigurationManager.AppSettings["Param1"], you will use Config.Param1. So you won't need to test the property DesignMode.
There are so many ways to do this, IMHO.
One thought that immedidately comes to mind would be to use an inheritance-based approach for the user controls in question? That way, in the base class, you can put that if (DesignMode) check in, and do the correct branching from there.
// if i were to visualizeyour lib.dll data initializer call like this:
class BaseUserControl
{
// i'm guessing that you initialize the data somehow...
void InitializeData()
{
if (!DesignMode)
{
InitializeDataLocal();
}
}
protected virtual InitializeDataLocal()
{
// whatever base behavior you want should go here.
}
}
// in the derived classes, just put the code you currently have for
// fetching the data from lib.dll here...
class UserControl : BaseUserControl
{
protected override InitializeDataLocal()
{
// fetch from lib.dll...
// optionally invoke some base behavior as well,
// if you need to...
base.InitializeDataLocal();
}
}
we use the nunit.exe application to run our (integration)test
Now i experience the problem that the connectionstring is not picked up from the app.config from the dll where the testcode is in.
That sounds logical because the nunit.exe is the starting app and not the test dll (it used to work when i started the tests from the visual studio testframework by the way), but should i put the connectionstrings in the nunit.exe.config?
I tried setting them in the testcode (works for the appsettings : ConfigurationManager.AppSettings.Set("DownloadDirectory", mDir);) like this:
ConfigurationManager.ConnectionStrings.Add(conset); (where conset is a ConnectionStringSettings object), but then i get the error that the connectionstrings section is readonly.
What should i do to use the connectionstrings in my test?
EDIT:
we use the entity framework so we can't put the connectionstring in the appsettings because it reads from the section directly, i couldn't find a way to work around this behaviour.
Using reflection, you can (in memory) change your value of the Configuration.ConnectionStrings[connectionName], which in your case you would probably do in SetUp or perhaps TestFixtureSetUp. See http://david.gardiner.net.au/2008/09/programmatically-setting.html.
// Back up the existing connection string
ConnectionStringSettings connStringSettings = ConfigurationManager.ConnectionStrings[connectionName];
string oldConnectionString = connStringSettings.ConnectionString;
// Override the IsReadOnly method on the ConnectionStringsSection.
// This is something of a hack, but will work as long as Microsoft doesn't change the
// internals of the ConfigurationElement class.
FieldInfo fi = typeof(ConfigurationElement).GetField("_bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic);
fi.SetValue(connStringSettings, false);
// Set the new connection string value
connStringSettings.ConnectionString = connectionStringNeededForNUnitTest;
I realize this is not the answer you are looking for, but it is the one I applied to solve your same problem:
You can modify, in EF5 and EF4.3 at least, your DbContext implementation and add a constructor that accepts a hard coded connection string, such as this:
public partial class MyContext : DbContext
{
public MyContext() : base("name=MyContext")
{
}
// --- Here is the new thing:
public MyContext(string entityConnectionString) : base(entityConnectionString)
{
}
// --- New thing ends here
// .... the rest of the dbcontext implementation follows below
}
You would have to paste this thing in every time you regenerate your context, but IMHO it's worth the hassle. The connection string has to be entity framework formatted with your metadata and everything, but you will be able to figure it out. Just keep it somewhere so you can paste it in whenever necessary.
You can read Connection String Value from ConfigurationManager.AppSettings, yes it is readonly. You can change it in App.Config.
If you want to change some values in connection string, for ex URL, in code you can change your dataContext.URL or any properties you want with coding.
I think for unit tests it may be much easy. you may put connection string into a test class directly as hardcoded string. in simple unit tests you test limited logic scope and not care of authentically of input arguments