I am new to .net and I usually had a common file which was having information of username,server,password,IPS and fixed integers in php and asp classic which i used to include in all files so that i could use them in any page. Since I have come to know that .net has no include function. how i can do it in asp.net?
Thank You
You wouldn't necessarily use an include file for sharing variables across a site. In .Net you would normally store values like this in the AppSettings section of the web.config file.
You can then access the values using code like:
string username = WebConfigurationManager.Appsettings["Username"];
Strictly speaking if working with application configuration (such as DB connection strings) these are placed in web.config for web applications and app.config for others.
There's also settings files.
Check out ConfigurationManager.
Other than that you must remember that "global variables are bad mmmkay" and aside from the various configuration files the nearest that you get to them would be public classes and properties.
In addition to AppSettings mentioned by Digbyswift, & webconfig (which I would also recommend), you could use a module:
Module Module2
Public MyGlobalInteger As Integer = 0
End Module
Then it can be called from anywhere like:
Dim someOtherNumber As Integer = MyGlobalInteger + 5
Though, you may want to make it readonly, depending on your usage.
Related
I'm working on my first Windows .Net application (as opposed to a .net web app, which I've done a lot of), and I have a question about database connection strings - is there an equivalent to the section in web.config?
I want to be able to have the program run against our test database (which will required a different connection string. What is the "canonical" way to define connection string objects in a Windows .Net application?
Thanks
Rather than write this all down again, here's a good article on this subject:
Storing and Retrieving Connection Strings
Add an "application configuration" file to your project. It will add a file called "app.config" Put your connection in there.
When the app is compiled it will change the name of the config file to match your executable. For example: MyApp.config.
I'm not sure what you mean by "canonical" way to define connection string objects. Name them whatever you want. Sometimes we use the name of the database, sometimes just the name of the project.
With regards to having multiple config files, we use Config Transforms. Which name them app.config, app.debug.config, app.release.config, etc. and use configuration manager to define which one to use based on where it's being deployed.
Non ASP.Net apps simply use app.config instead of web.config. See here.
Connection strings can be stored as key/value pairs in the
connectionStrings section of the configuration element of an
application configuration file.
I have a couple of web applications whose source code is missing. The project is compiled to a dll and is hosted on a IIS.
I have couple of questions to make.
What is the best way to recreate the
project from the dll file??
We are planning to change the
database server, and the database
connection strings are specified in
the Global.asax ( I mean the public
class Global : HttpApplication ). Is
there a way I can subclass this
Global and override the connection
strings? If yes, how can I make the
IIS refer to the new dll
Thank you all for any suggestions!!
For first part, use decompiler tools such as Reflector/ILSpy/dotPeek to convert IL code from DLL to higher level language such as C#. However, tools cannot get back comments, local variable names and project structure. You need to manually organize the code into files and project structures. From aspx files, you have to figure out the code-behind classes and then link up the source of the class into a correct named code-behind file - for example, if default.aspx says that it inherits from MyApp.Default then create file default.aspx.xs and put the source code for the class into that.
For second part, you can create a new class derived from Global and modify Global.asax to use that class - you need to put the assembly containing new class in bin folder and overwrite inherits clause in asax file to point to the type name of new class. You anyway need to inspect the code of your current Global class (using tools sighted above) to see if you can override connection strings by sub-classing.
Probably the best tool available to reverse engineer a dll into code is .NET Reflector. Unfortunately, the latest version is no longer free, but it is worth the money.
I am not sure exactly if this still applies if you can already reverse engineer your source code. However, I would recommend moving your connection strings outside of your project into web.config as a best practice. This way you can make the change in the future without changing any code.
This might sound a bit dumb.
I always had this impression that web.config should store all settings which could be subject to change post-build and setting.settings should have the one which may change pre-build.
but I have seen projects which had like connection string in setting.settings. Connection Strings should always been in web.config, shouldn't it?
I am interested in a design perspective answer.
Just a bit of background:
My current scenario is that I am developing a web application with all the three tiers abstracted in three separate visual studio projects thus every tier has its own .settings and .config file.
Web.config is mostly meant for configuration, and it also stores the default values of your settings.
Settings.settings is just a convenience file for Visual Studio to provide a UI for editing your settings.
The .config comes in two different flavors: App.config for Windows applications, which will be named YourApplication.exe.config, and the Web.config for web applications. They share the same schema, syntax, and options.
You may notice that if you add a setting to Settings.settings, it gets added to the .config as well.
The .config must be deployed with apps, but Settings.settings doesn't need to.
Setting.settings is a class, it is not used to store the connection string as such, it is used to expose a specific connection string from web/app.config as a property on a class. VS does also tend to hard code a default value if the particular connnection string cannot be found.
Intro:
Normally we store ConnectionStrings and some other settings (<appSettings> <add key...) in the Web.config or App.config.
My scenery:
Web application using factory pattern
with direct injection to read data
providers.
In the web.config I have the key
that tells me which DLL (provider)
will I use to retrieve my data.
I can have more than one provider
(each DLL will be a provider for MS
SQL, MySQL, or get the data from
some SOA service).
Each DLL has his own name (ID and namespaces) and will need to have is own
configurations (dataconnections,
service urls, etc...) , the first
idea is to write then in the
app.config.
Problems:
#1 - The website is running (runtime) I need to change the Data Provider, how can I do this? Somehow the default value written in the Web.config will be changed.
My objective is to be able to have multiple providers (and during runtime: add/delete providers and change configurations) - this leads me to my second problem:
.
#2 - Each Data Provider has custom configurations and App.Config files do not work with dll assemblies, only executables. This means that I need to write then on my Web.Config (I do not like this option, because once again I am updating my web.config in runtime). how can I solve this?
I am trying to avoid to write a custom settings XML file. My ideal solution is to deploy somehow the DLL and DLL.config per each provider. And once again during runtime I may need to change this configuration values.
.
Ok guys, while I was waiting for some help I put my hands to work and I was able to find a good solution (in my opinion of course :P).
Let me share it with you:
So, I have one web application, or one console application, or some other kind of application, and lots of class library, and I need to store informations (different per Visual Studio project) that will change during runtime.
Storing this information inside the Web.config or App.config is not a good idea for the many problems it takes.
The other way I see it is to have one XML config file per project.
Each application will read his own XML and add it to the Cache with CacheDependency (will expire when the XML config file is updated). This way we will not need to read the configuration all the times, and we also know when the configuration is changed.
IMO THIS IS THE FASTEST AND EASIEST WAY TO SOLVE THE PROBLEM, no need to use 3rd party frameworks (neither the time it takes to learn/program it).
.
Example code:
protected void Page_Load(object sender, EventArgs e)
{
DBConfiguration cachConf;
cachConf = Cache["cachConf"] as DBConfiguration;
if (cachConf == null)
{
cachConf = new DBConfiguration();
XmlDocument doc = new XmlDocument();
doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/MyConf.xml");
XmlNodeList xnl = doc.GetElementsByTagName("username");
XmlElement xe = (XmlElement)xnl[0];
cachConf.Username = xe.InnerText.ToString();
xnl = doc.GetElementsByTagName("password");
xe = (XmlElement)xnl[0];
cachConf.Password = xe.InnerText.ToString();
Cache.Insert("cachConf", cachConf,
new System.Web.Caching.CacheDependency(
HttpContext.Current.Request.PhysicalApplicationPath + "MyConf.xml"),
DateTime.Now.AddMinutes(60), TimeSpan.Zero,
System.Web.Caching.CacheItemPriority.Default,
new System.Web.Caching.CacheItemRemovedCallback(
CacheItemRemovedCallBack));
}
LabelUsername.Text = cachConf.Username;
LabelPassword.Text = cachConf.Password;
}
private void CacheItemRemovedCallBack(string key, object value, CacheItemRemovedReason reason)
{
//Response.Write("Hello world");
}
You could store the credentials in a secondary config file referenced from web.config as follows:
<appSettings file="AppSettings.config"/>
You would still need to be careful to avoid editing conflicts on the external file.
Problem 1 - Runtime changes:
The solution that Microsoft hopes you apply to this type of problem is to simply keep the web server stateless. When an ASP.NET application recycles, it lets existing requests complete new requests start on a new process. For background, read about IIS Process Recycling. A change to web.config recycle the worker process, but users will not notice this (unless you keep state in the web server process). That's the MS design.
If you want to monitor for changes without recycling a process, you'll want something other than default web.config behavior. An example that comes to mind are cruise controls project files. They have a component that maps objects to and from xml, using that, you can use the FileSystemWatcher class to monitor for changes.
Problem 2 - Custom configurations:
It sounds like you have components from different libraries that have different dependencies. Your main assembly needs a means to instantiate a service, with a given set of dependencies. The MS data provider model is cool, but not this cool.
To be this cool, use an inversion of control container, because this is exactly what they do. I like autofac (because I like the Philip K Dick reference), but castle windsor is great.
Now, if you are talking about changes databases or data providers on the fly, it may be that configuration is not the right place. If your are reporting against x databases of y types, you need a central repository of that database information, and a configuration file is not the right place, nor is an IOC container the right solution.
As Precipitous suggested, try Castle Windsor:
http://www.castleproject.org/container/
You're doing Inversion of Control manually. Windsor will take the burden off of you.
if you have a class library project that acts as ur DAL and it has an App.Config file with connectionstrings, how can I force it to use that config file? It keep getting values from the web.config in my Web Application project.
The DAL project uses LinqToSql. When I instansiate a DataContext object in my Web Application, from the referenced DAL Class Library project, can I make it use it's app.Config connectionstrings? It seems to ignore this file and tries to pick up connectionstrings from the web.Config connectionstrings node. There are no connectionstrings present there.
Any help is appreciated. A colleague mentioned making the app.Config in the DAL and embedded resource. Does that sounds like a good idea?
Thanks,
~ck in San Diego
Web applications always use web.config. Desktop applications always use app.config.
how can I force it to use that config file? It keep getting values from the web.config in my Web Application project.
You can't. If you use the System.Configuration classes, they will always pull from the active application's .config file (app.config for executables, web.config for asp.net websites).
Workarounds include using file i/o for reading your settings out (as opposed to the System.Configuration namespace) or putting your DAL configuration information in the appropriate .config file (the more common choice).
I'm not sure, but take a look at that:
using System.Configuration;
ExeConfigurationFileMap Map = new ExeConfigurationFileMap();
Map.ExeConfigFilename = FileName;
Configuration Conf = ConfigurationManager.OpenMappedExeConfiguration(Map, ConfigurationUserLevel.None);
AppSettingsSection section = (AppSettingsSection)Conf.GetSection("???");
Here's how I think of a *.config file. Say you have a method in your DAL:
DoSomething(connectString, SqlDialect, businessObject)
Since connectString and SqlDialect don't change with every call to this method, it would be nice to be able to remove those parameters and get those through some other means.
Well, *.config files are there for that reason--they are not only environment-specific, they are also app-specific. It's so your Web app can say, "Hey everybody, connectString = "..." and SqlDialect = "...", for every method call, until I say otherwise."
Let's say you want one app to log into SQL with one set of credentials, and another app to use another set of credentials (with different perms if necessary) so that the DBA can keep track of which app is doing what (if he/she so chooses). Well, *.config files make this happen.
That's why the app that you're running is the one that provides the *.config file. So just cut all the contents from your DAL's app.config file and paste it into your Web.config file, then delete App.config. You should be good-to-go after that.