|
hi there,
i recently developed a custom SettingsProvider to save application & user settings in a SQL CE Database instead of app.config and user.config files. everything works fine when the SettingsProviderAttribute is applied to the VS generated Settings class.
But it seems that the Settings Designer is coupled to file configuration and doesn't rely on the functionlity of the corresponding SettingsProvider.
Using my SettingsProvider with the VS generated Settings class works fine in code, but i wonder if there is a way to use the VS Settings Designed to add new settings to the application.
when i try to synchronize the designer with the settings it just tells me that "No user.config files were found in any of the following locations:" .
The point is that i don't need user.config files because everything is stored in the database.
is there a way to tell the settings designer to rely on the settingsprovider functionality instead of doing it itself?
thanks for any comments
joachim
|
|
|
|
|
I have no idea, perhaps creating a Visual Studio Plug In might provide a solution. If you get it figured out it might make a good CP article.
Good luck
led mike
|
|
|
|
|
Hi there,
This query is with respect to the isolation of object in a collection. And like to hear couple of approaches those are feasible in such scenario.
First, let me explain the problem which I am facing at this time. Our application has few rules (objects in concize) associated with few entities, those are editable for all currently active users (U1, U2). Assume that, we have 2 rules (R1, R2). Our requirement is no two users can edit, delete or modify a specific rule at same point of time.
Eg: If U1 update R1 then U2 has to wait till U1 release R1. If U1 update R2 then U2 have provision to update R1 since R1 is not locked by any user. I hope you are clear about the requirement.
Now, to ensure the above discussed functionality we implemented a method which uses Interlocked Class in threading namespace (VS.NET & C#). This approach in fact helps us while avoiding concurrent user access over a specific instance on a specific time using some flag value. But the problem is, it locks the entire rule collection (R1, R2) even thou there is no concurrent user. I presume, this is because of the way we model the class and is a collection (rule collection).
Eg: If I have N rules in rule collection, it doesn’t mean that I need to lock all N rule objects in the rule collection. But I only need to lock specific rule (subset of rule collection), those are currently used by some logged users. And ensure all other non affected rules are free from lock.
I did have a thought on the object level locking using .Net object locking mechanisms. But this is practically impossible to implement locking mechanism for each and every functionality.
FYI: It is small product which has 54 projects (30 services, test projects, script) in C#.NET. And the product has its 70% of functionalities in place. So a major rework in object level is not practical at this moment since it has to go through lot of review and regression process.
I hope you are clear with respect to the problem statement.
Can you explain me which method would be feasible in such scenario ?
How will i make sure only the object lock is available for the object which is currently i use and not other objects in the collection?
And how will I ensure object level isolation than locking an entire collection?
Do we have any proved patterns for this kind of problems?
Thanks in advance. 
|
|
|
|
|
Dealt with in the Design section.
|
|
|
|
|
So I want to create an instance of SqlParameterCollection. The problem is that it's impossible to do without reflection. What a pain in the ass...
SqlParameterCollection collection = (SqlParameterCollection) typeof(SqlParameterCollection).
GetConstructor(BindingFlags.NonPublic|BindingFlags.Instance,
null, Type.EmptyTypes, null).Invoke(null);
WTF was Microsoft thinking?
Why was it so hard to allow this instead?
SqlParameterCollection collection = new SqlParameterCollection();
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
They did it because the Parameters are instantiated from the command. There's no real reason to use them with anything other than a SqlCommand object, so no need for anything other than the SqlCommand to actually create it.
|
|
|
|
|
I know they're only needed by SqlCommand objects, but I have a need to create the parameter list OUTSIDE of the confines of the SqlCommand object. There's absolutely no rational reason for preventing us from instantiating the collection outside of the command object.
IMHO, it's an arbitrary restriction, not one made from sound design requirements.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: but I have a need to create the parameter list OUTSIDE of the confines of the SqlCommand object.
WTF John? How can you "need" it if you agree they are only needed by SqlCommand?
led mike
|
|
|
|
|
I wrote a function in a class that accepts a stored procedure name and, curiously enough, an SqlParameterCollection, and returns a DataTable - all of the nasty sql stuff is contained in the function, reducing a storedproc call to blackbox status. Silly me for thinking it would be possible to instantiate a class that is otherwise available via SqlCommand.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
You could always pass in the parameters as a List<SqlParameter>. It's a hack, but you could do it.
|
|
|
|
|
Pete O'Hanlon wrote: It's a hack, but you could do it.
I'm probably missing something obvious but why is that hack? 
led mike
|
|
|
|
|
led mike wrote: I'm probably missing something obvious but why is that hack?
I just mean that it's not a SqlParameterCollection, it's a collection of SqlParameter items. Potayto, potahto.
|
|
|
|
|
Pete O'Hanlon wrote: Potayto, potahto.
Not quite (ses my other response).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Actually, the parameter should be IEnumerable<SqlParameter>. That way you can send in any kind of collection of paramters, like a list or an array.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Actually, the parameter should be IEnumerable<sqlparameter>. That way you can send in any kind of collection of paramters, like a list or an array.
Or indeed IEnumerable<DbParameter> to get round the whole "hey I need a SqlCommand" issue. 
|
|
|
|
|
Pete O'Hanlon wrote: Or indeed IEnumerable<dbparameter>
Or May be IEnumerable<IDbParameter>
You have, what I would term, a very formal turn of phrase not seen in these isles since the old King passed from this world to the next. martin_hughes on VDK
|
|
|
|
|
Yeah, and I even considered doing that for about three minutes, and then decided it was a hack (although no less of a hack than using reflection).
Besides that, putting the parameters into a list would have required the extra overhead of traversing that list in order to fill the SqlCommand's internal collection object, where simply assigning the collection requires just one line of code.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
modified on Wednesday, February 27, 2008 10:58 AM
|
|
|
|
|
John Simmons / outlaw programmer wrote: Besides that, putting the parameters into a list would have required the extra overhead of traversing that list in order to fill the SqlCommand's internal collection object, where simply assigning the collection requires just one line of code.
No it wouldn't. You would use Parameters.AddRange to add the parameter collection. You should never traverse a collection to add it to another collection. You should always look to use the AddRange method (if available) as it's much more performant.
|
|
|
|
|
John Simmons / outlaw programmer wrote: I wrote a function in a class that accepts a stored procedure name and, curiously enough, an SqlParameterCollection, and returns a DataTable - all of the nasty sql stuff is contained in the function
Well, no. If you have the SqlParameterCollection being passed into the method, then "all of the nasty SQL stuff" is no longer contained just in the method.
|
|
|
|
|
The class is a generic class that simply handles all of the SqlConnection, SqlCommand, and SqlDataAdapter stuff with the requisite exception handling. All I have to do to instantiate the object is pass in either a query string or a app.config keyname for the query string, and then call the appropriate function, some of which allow you to pass parameters. Granted, I could have written a class that inherited my SQLQueries class to hide even the SqlParameterCollection stuff, but that needed to be put off until later.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: So I want to create an instance of SqlParameterCollection.
You always have to do it through SqlCommand class. That is what serves as the factory for parameter collection. Parameter collection belongs to and works in close association with the command object. Things are internal or protected for a certain reason.
You are breaking Good OOP practices by using reflection. For instance, what will happen when in next version of .NET Microsoft decides to add a new internal constructor and decides to get rid of the default constructor. Your code will compile fine but will never run.
As people have suggested List<sqlparameter> is a slightly better option. But I would prefer to get rid of even that and use a method like this:
void ExecuteQuery(string query, IDictionary<string, object=""> values); </string,>
or even better
void ExecuteQuery(string query, params object[] values);
The later one requires a little extra work, but is a better option IMO.
You have, what I would term, a very formal turn of phrase not seen in these isles since the old King passed from this world to the next. martin_hughes on VDK
|
|
|
|
|
Hai
I need to add and remove rows dynamically to an html table on button click event. In my code only one row is created and that row removes on another click.
Please help me
|
|
|
|
|
Please don't cross post.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Any microsoft's UI toolkit for .Net?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
