|
We can use .net class (Manage code) in using clause it will automatically goes out of scope. You don't need to close or dispose out side, Because they called dispose function.all the class which is implemented the idisposable intercace will work on using clause
|
|
|
|
|
using keyword is nothing but a syntactic sugar over try-finally construct. For example, the following code
using (SqlConnection conn = new SqlConnection(...)) {
....
....
....
}
actually gets compiled to
SqlConnection conn = new SqlConnection(...);
try {
....
....
....
}
finally {
if (conn is IDisposable) {
conn.Dispose();
}
}
Therefore, irrespective of whether an exception is thrown or a return statement is encountered, the finally blok is always executed and ensures that objects that implement IDisposable are always cleaned up (unless the runtime host chooses not to do so - just to complicate things).
|
|
|
|
|
Exception message:
"Unrecognized attribute 'valid'. Note that attribute names are case-sensitive.
I used to have a field called "valid" in one of my configuration elements, but through the course of development it's now obsolete, so I'd like to remove it. I removed it from the ConfigurationElement subclass, and now when I try to read the config section (via config.GetSection), I get the above exception, which then makes my config section variable null, blah blah blah, no saved config = program effectively unusable from session to session.
Google fails me. MSDN fails me. Internet fails me.
I'm new to the ConfigurationManager, having only ever done equivalent functionality through .ini files before, so I'm sure there's probably just some "cleanup" command I can do that I'm just not aware of.
modified on Friday, October 23, 2009 2:41 PM
|
|
|
|
|
I believe you are writing a class to read configuration values from a config class. You have removed the 'valid' element from the spec but not from the config file. I think, removing the 'valid' element from the config file should solve your problem.
|
|
|
|
|
Yes, that's more or less the problem, but since it's using the ConfigurationManager, the actual config file operations are completely hidden (as far as I know), or at least I don't know where to find it.
|
|
|
|
|
What kind of app r u developing? Windows or Web ? Whatever it is you should have full control over your config files.
|
|
|
|
|
It's a Windows app using the built-in ConfigurationManager .NET capabilities. I based it on this MSDN code sample[^]. Maybe it'll be easier to just show some code:
Configuration classes:
public class SerialConfig : ConfigurationElement
{
[ConfigurationProperty("valid",
DefaultValue = false,
IsRequired = false)]
public bool Valid
{
get
{
return (bool)this["valid"];
}
set
{
this["valid"] = (bool)value;
}
}
[ConfigurationProperty("baud",
DefaultValue = 115200,
IsRequired = true)]
public int Baud
{
get
{
return (int)this["baud"];
}
set
{
if((value == 115200) || (value == 9600))
{
this["baud"] = value;
}
else
{
}
}
}
[ConfigurationProperty("name",
DefaultValue = "",
IsRequired = true)]
public String Name
{
get
{
return (string)this["name"];
}
set
{
if (value.Contains("COM"))
{
this["name"] = value;
}
else
{
this["name"] = "INVALID";
}
}
}
public SerialConfig(String name, int baud)
{
this["baud"] = baud;
this["name"] = name;
}
public SerialConfig(string name)
{
new SerialConfig(name, 115200);
}
public SerialConfig()
{
new SerialConfig("INVALID", 115200);
}
}
public class SerialConfigSection : ConfigurationSection
{
public SerialConfigSection()
{
this["serialConfig"] = new SerialConfig();
}
[ConfigurationProperty("serialConfig")]
public SerialConfig serialConfig
{
get
{
return (
(SerialConfig)this["serialConfig"]);
}
set
{
this["serialConfig"] = value;
}
}
}
Actual usage of configuration
public static void InitializeConfig()
{
Configuration userConfig =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal);
ExeConfigurationFileMap configFileMap =
new ExeConfigurationFileMap();
configFileMap.ExeConfigFilename =
userConfig.FilePath;
config =
ConfigurationManager.OpenMappedExeConfiguration(
configFileMap, ConfigurationUserLevel.None);
EITPortConfig = null;
BridgePortConfig = null;
try
{
EITPortConfig = (SerialConfigSection)config.GetSection("EITCOMPort");
BridgePortConfig = (SerialConfigSection)config.GetSection("BridgeCOMPort");
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("EITCOMPort");
ConfigurationManager.RefreshSection("BridgeCOMPort");
if (EITPortConfig == null)
{
EITPortConfig = new SerialConfigSection();
EITPortConfig.SectionInformation.AllowExeDefinition =
ConfigurationAllowExeDefinition.MachineToLocalUser;
EITPortConfig.SectionInformation.AllowOverride = true;
config.Sections.Add("EITCOMPort", EITPortConfig);
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("EITCOMPort");
}
if (BridgePortConfig == null)
{
BridgePortConfig = new SerialConfigSection();
BridgePortConfig.SectionInformation.AllowExeDefinition =
ConfigurationAllowExeDefinition.MachineToLocalUser;
BridgePortConfig.SectionInformation.AllowOverride = true;
config.Sections.Add("BridgeCOMPort", BridgePortConfig);
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("BridgeCOMPort");
}
}
catch (ConfigurationErrorsException e)
{
Console.WriteLine("[Exception error: {0}]", e.ToString());
}
}
|
|
|
|
|
Your solution must have a default configuration file (app.config) that is used as a template to create local copies during deployment. For example, if you app name is myapp.exe, then your configuration file name during deployment is myapp.exe.config. Changing the app.config should solve your problem.
|
|
|
|
|
In the InitializeConfig() method, debug and check the value of userConfig.FilePath property. I think that should tell you the configuration file path.
|
|
|
|
|
Thank you! That finally resolved the issue. I knew it had to be lingering around somewhere.
|
|
|
|
|
Hi all,
I think this can trigger a nice discussion about .net capabilities.
I want to have a big single assembly with dozens of functionality groups, but I don't want them to be uploaded into memory until they are really needed.
This is a proof of concept, trying to demonstrate the best way to deploy a multi-mission application that has all possible functionalities in a single assembly, and, according to configuration, will run use specific classes.
The purpose is to ensure to distribute all functionalities in a single file and avoid branching problems without memory costs.
Thanks in advance.
Best regards,
Jaime.
|
|
|
|
|
Just put all your assemblies in a zipfile and load them on demand. You can also put them in a SqlCE database and load them from a BLOB-field
"The city’s central computer told you? R2D2, you know better than to trust a strange computer!"
-- C3PO
modified on Tuesday, September 8, 2009 3:20 AM
|
|
|
|
|
Hmm, not sure if it will be practical. Database approach is discarded, but embedding dlls into a single assembly can have some benefits. Still have to think on that, specially how to avoid to add complexity to the "consumer" code.
Best regards,
Jaime.
|
|
|
|
|
Jaime Olivares wrote: Hmm, not sure if it will be practical.
I found that multiple assemblies are more practical; you load the pieces you need, and keep 'em together in a folder. One could also compile everything into a massive DLL, but that's harder to update (you'd have to replace the entire thing, or overwrite a piece of it with binary data) and I doubt that .NET will optimize the memory-usage.
Jaime Olivares wrote: embedding dlls into a single assembly can have some benefits.
For distribution, yes
I fail to see the advantages for a deployed application yet. Perhaps you can explain that a bit more in detail?
"If you automate a mess, you get an automated mess."
-- Rod Michael
|
|
|
|
|
Eddy Vluggen wrote: One could also compile everything into a massive DLL, but that's harder to update (you'd have to replace the entire thing
That's the idea! I don't want to replace one or two dlls and leave others untouched. At some point, this becomes a mess which is hard to manage.
Best regards,
Jaime.
|
|
|
|
|
Jaime Olivares wrote: At some point, this becomes a mess which is hard to manage.
How so?
Jaime Olivares wrote: I don't want to replace one or two dlls and leave others untouched
If they haven't changed, why update them?
only two letters away from being an asset
|
|
|
|
|
I have dozens of products, all them sharing dozens of components. I can update a component that affect many products, of just specialized functionality that affects one specific product.
My intention is to have a secure distribution of the components' suite, prefereably as a monolithic big component, besides the specialized functionality that with a plugin approach.
Best regards,
Jaime.
|
|
|
|
|
Jaime Olivares wrote: prefereably as a monolithic big component
Hello, the 80's are gone. This is the 21st century, time to update your skills for the real world.
only two letters away from being an asset
|
|
|
|
|
Jaime Olivares wrote: I want to have a big single assembly with dozens of functionality groups, but I don't want them to be uploaded into memory until they are really needed.
You can't control this with a single assembly. The call to LoadAssembly works on a single file, not parts of it. The best way for this type of functionality is to use multiple assemblies and only load what is necessary. If you use separate AppDomains you can also cleanup unused assemblies and recover memory and resources if that is an issue. Some techniques that were used here[^]
only two letters away from being an asset
|
|
|
|
|
Multiple assemblies is exactly what I am trying to avoid because I have a dll hell. Consider a scenario with a dozen of dlls that are updated monthly. The single assembly points to reduce the risk of unsynchronized dlls.
Best regards,
Jaime.
|
|
|
|
|
Consider a scenario where you have a different architecture then. To my knowledge what you are asking for can't be done.
How large will this single assembly be? How large will it grow? If only one method in one class gets updated you have to recompile and distribute the entire assembly? Again, IMO, you need to reconsider this strategy. You are adding complexity to solve a simple problem.
only two letters away from being an asset
|
|
|
|
|
Hi again,
Mark Nischalke wrote: How large will this single assembly be? How large will it grow?
Application can be about 10-20 MB executable, which takes even more when loaded on memory.
Mark Nischalke wrote: If only one method in one class gets updated you have to recompile and distribute the entire assembly?
Yes and no. Just in few cases one method is changed, releases are frequent and many components are changed because all them are highly interconnected.
Updating just some components is always a risk and produces potential branching problem. A different combination of components is used depending on specific product.
So my intention is to release always the entire suite of components, prefereably in a single assembly.
Best regards,
Jaime.
|
|
|
|
|
Jaime Olivares wrote: Application can be about 10-20 MB executable
Rediculus!
Enough said on this subject. Good luck
only two letters away from being an asset
|
|
|
|
|
Jaime Olivares wrote: releases are frequent
So you want the suer to download the entire "monolith" every time there's an update to a single method instead of a much smaller .DLL that encloses just the one component that was changed?? How much bandwidth are you allocating to this again?
Jaime Olivares wrote: Updating just some components is always a risk and produces potential branching problem.
Only if you release components without testing them against the current versions of others.
Jaime Olivares wrote: A different combination of components is used depending on specific product.
Then I guess you'll have to manage each site that the componet can be a part of. This will, of course, make your job a little hard because now you have to test each component against each application that it will be used in.
Jaime Olivares wrote: So my intention is to release always the entire suite of components, prefereably in a single assembly.
Have you thought about packaging up all the related components into a .ZIP and having the app download that .ZIP and unpackaging it?
|
|
|
|
|
Dave,
Thanks for following, still want to explore all possibilities:
Dave Kreskowiak wrote: So you want the suer to download the entire "monolith" every time there's an update to a single method instead of a much smaller .DLL that encloses just the one component that was changed?? How much bandwidth are you allocating to this again?
Bandwidth is not a problem, I can manage terabytes, literally. But a good patch algorithm can be applied to minimize this.
Dave Kreskowiak wrote: Only if you release components without testing them against the current versions of others.
The proposal is to test the whole suite of common components first, and later the products. There are lots of implicancies when updating just single components. So the safest way to be sure is to update all them, without major analysis.
Dave Kreskowiak wrote: Then I guess you'll have to manage each site that the componet can be a part of. This will, of course, make your job a little hard because now you have to test each component against each application that it will be used in.
The scenario is more or less the following: a single component suite in every machine, monolithic can assure 100% update. But still is just an option. Applications can be added to every station, or maybe they are already there, update of component suite and application should be independent. Even they are architectured to have a loosy coupling to avoid branching and versioning problems, due to high rate of updates.
Dave Kreskowiak wrote: Have you thought about packaging up all the related components into a .ZIP and having the app download that .ZIP and unpackaging it?
Well, this is the obvious choice, even complies with the "monolithic" in some aspects, but I want to avoid the scenario where some dlls are updated and others aren't (it happens, for lots of reasons).
Best regards,
Jaime.
|
|
|
|