Yes, I meant that the maximum would be 1/2 in a day, but maybe once every few months. Certainly not 1 or 2 every day.

I don't expect *too much* churn of the plug-ins, (1, maybe 2 in a day) and the app domain is cycled every night by default so I'm not too worried about the old plug-ins stacking up and causing memory/performance issues. (If I've misinterpreted the outcome of the limitation you described, please set me straight). That being said, thanks so much for your answer. I'm so glad I posted this here, I've got some great information, and great leads to follow. I've been reading with eyes wide open all afternoon. ;P Todd

I am developing a system that I'm trying to keep as generic as possible. It is capable of implementing/executing business rules that should be defined in another file/assembly. For sake of explanation, I'll segment the idea into the "generic system" and "business system". If the "business system" were to change or require an update, then that should be possible without releasing the "generic system". Let's say the generic system monitored a folder, and if a file associated with the new version of the business code was dropped into that folder then it would be accessed, and if the version was > than the current one, then the generic code would start using it. The business code could have a factory method like GetEventProcessor(guid) that would return a delegate (from the "business system" (with a consistent signature) that is associated with the guid passed into GetEventProcessor. I'm looking for examples of or ideas about a mechanism whereby code with a defined interface can be picked up and integrated into execution of another piece of code at run time. I have found some articles about plug-in based architectures in .net. Developing this type of system is new to me, and as I peer down the barrel of this possibility, I thought I'd pose the question here in hopes of harvesting some opinionated ;) guidance, warnings and/or advice. Any ideas are welcome. Thanks Todd

I love pompous know-it-all responses that don't answer the question. Christian, it seemed pretty obvious that the code was written for purposes of demonstrating the problem and was not supposed to be "production code". Feel free to spend as much time as you'd like refactoring it and bringing it up to your standard. I did some additional reading, and found this very helpful knowledge base article about stabilizing culture specific behavior in asp.net apps - if anyone else has a similar question in the future.. http://support.microsoft.com/kb/326943[^]

Hello I have been trying to debug a problem with a web app that I am responsible for and have traced it down to a very specific problem. To demonstrate that problem, I have written a little web app, and I'm sure someone here can direct me quickly to the source of the problem.

   Try
        Me.Label1.Text = ""
        Me.Label1.Text = Date.Parse(Me.TextBox1.Text).ToShortDateString
    Catch ex As Exception
        Me.Label1.Text = ex.Message
    End Try

When I run this on serverA it with the input of '7/30/2007' it fails with the exception message being: 'String was not recognized as a valid DateTime' When I run it on any other server, it works fine. On serverA, if I input '30/1/2007' it works. If I input that value on any of my other servers it fails with 'String was not recognized as a valid DateTime' The question is, what server configuration value do I need to change on the server to make that server behave the same as the other servers. These are all windows server 2003 servers, and I checked the regional settings in Control panel and the failing and passing servers have the same regional settings values (english US) and the same long/short date format in the regional settings. Apparently that does not affect this date.parse behavior. This kind of problem scares me because it introduces a significant likelihood of wierd flaky problems and behavior. If the date value had been '2/5/2007' it would've worked on both servers and it would have been hard to identify why all the data was messed up. Any help or guidance would be appreciated.

The system as it exists now, asks users questions and gets answers, and then stores the information for retrieval and processing by other stakeholders, who then apply their own business rules to the data. Afterward, the question and answer data must be retained for a long time, and cannot be changed after it is entered. The conceptual view that I was referring to, is the fact that there is a *coffee* table at all, versus just having very generic questions and answers. Following your example, if there was a requirement to add a question about tea, then they would have to create the "tea_additions" table and so on. This can get very complicated as the complexity of the business is realized, and this is how I am perceiving the business to be intertwined with the dB design, I am exploring the removal of "coffee" and "tea" from the dB altogether in favour of generic Questions and answers in order to mitigate that complexity. The problem is, I may be just shifting around the complexity for little actual benefit?

Hi Todd I agree, I also don't think there is a right or wrong answer. One of the big drivers for the redesign of the system I have in mind (that I originally mentioned) is the significant complexity and lack of flexibility built into the previous system. I place a big hunk of blame for this on the tight integration of business concepts into the data store - which I (agreeing with James Simpson) think should be kept ideally as generic as possible. I expect to receive resistance to this idea because a number of the stakeholders played a part in the development of the current system and are not going to consider a drastic change to be attractive, and hey - maybe they're right.. I was hoping to be able to find some kind of architectural book or something like that to help me to objectively explore the benefits of either direction so I can find a balance that is acceptable. Already James Simpson mentioned in a previous post - the distinction between a database and a persistence model, and I hadn't really separated out those two concepts in my thinking yet, so I'm glad I posted this here.

:-) lol ok, well I guess I just disagree then, because I think "the people" would help articulate the context if it was read three months later.

Hi James Thanks for your answer, but I'm afraid my intended point is being missed. Obviously the example was simplistic. The initial question is related to whether or not the database should have an awareness of the business concepts or if it should be implemented in a more generic way. I'm trying to explore where the line should fall on the scale between the most generic representation of the data, and the most detailed.

lol I guess you're kind of right, but the big problem with context is that it's relative to the observer. If you have 92 people in the room they will each have their own context. Although if you were giving a speech in that room, you may consider the room to be a reasonable assumption of context. Then what about the person who is listening to an audio recording of that same speach, or what about the guy who's reading it three months later? Your interpretation of the statement is based on a presumption of context, and that often leads to miscommunications. Especially when making statements destined for a larger and often disconnected audience (likes the statements you were quoting).

I'm afraid of getting too dialled in to the specifics when it's really the larger idea that I'm wanting to explore. but let's say that the question is: What do you add to your coffee? A number of options are available and the user selects milk, and sugar. The distinction between the two concepts is this: Do you have a table that is called say: coffee_additions with a rows containing each possible thing people put in their coffee. (or however you might model that) - OR - Does the database have no interpretation of coffee at all, or what the answers are? The database only knows that it was a question, and there were numerous answer options provided, of which two were selected. I'm not sure if thats the best example, but I hope it illustrates the distinction between the two approaches.

perhaps it could be 'we, the programmers', or, 'we, the men', or 'we, the women' The qualification is valid I think because it sets the scope of "we".

Hey there I don't think this is a *programming question*, but if it is then I'm quite sorry for posting it here. It guess it might be, but it's more conceptual than programmatic. Anyway - to the question. I am in a position to consider re-designing a system which is highly dependant on a data store. A requirement of this data store is retention of data for a long period of time. The system is one that will store questions and answers as input by users of the system in such a way that the content of those questions and answers must be re-createable at some point in the future. The questions and answers are also processed with the application of business rules. There are a number of consumers of the data after it has been saved in the datastore, each with differring requirements. I don't want to get into too much of the specifics for sake of this question, but I am trying to explore the differences and benefits between two distinct approaches towards the databases role in the system. Approach1: As I mentioned, this is a "re-design". The system as it was/is implemented integrates the business concepts with the design of the database. The outcome of this approach is a complex database that contains business-defined relationships. These relationships are difficult to manage when they change because the old data is in the same data store but they provide more granular access to statistics and reports because some of the *meaning* of the data in integrated into the database already. Approach2: I am very interested in exploring the alternate concept where the database stores generic questions and answers only. The database has no knowledge or (interpretation) of the business at all. A weakness of this approach is that data must be re-assigned business meaning when it is to be used. I am interested in any articles or books or ideas that will help me to consider the benefits or weaknesses of both approaches. I expect that the outcome will be a layered approach with approach2 being the starting point, but I don't want to accept any duplication of data if it can be helped. Ideas? Thanks..

lol - the problem is I don't think I need that much ram or that many cores - I think I need a highly available and configurable R&D environment..

Hi there I am looking for insights and experiences about r&d facility arrangements in development teams. I am in a development team that is a part of a larger organization. We develop .net web applications. I have been a part of this team for 3 or 4 years. Initially, we had an R&D lab wherein we had a number of computers and servers that we used for trying things out, and doing impromptu configuration tests. Small *relative* performance comparison tests, etc... The larger organization has demonstrated a desire to eliminate these *rogue* servers from the larger network in favour of controlled VM's accessible via remote desktop that we have to write a business case to acquire, and even then they are only allocated for 3 months unless we write a business case for an extension. blah blah blah.. Needless to say, my initial response to this is resistance. I don't like the idea that we have to add another layer of disconnection and paperwork from the activity of research, experimentation or testing.. I think this will result in a reduction in the effectiveness of testing and add alot of friction to the fostering of innovation amongst our developers. All this being said, its an uphill battle to have anyone recognize these opinions to the degree required to justify and/or protect our lab - I need any real examples that can be provided regarding this issue - or if anyone knows of pertinent articles, that may be helpful as well. I'm going to need to come up with something that speaks to someone *upstairs*.. Any ideas are appreciated.

check this out: http://www.matrox.com/graphics/en/products/gxm/th2go/[^]

I have six PC's in my crawlspace (don't ask) all just on the other side of a wall that is common to my living room. I have a kvm switch in the crawlspace (pretty cheap), and I have a nice clean 3" hole drilled through the wall for the cables I need. I have a usb 2.0 dvd burner sitting on my desk connected to one of the systems and then shared to the other ones. I noticed when doing this that it's handy to disconnect the internal dvd/cd/floppy drives from those computers, (since you likely will not be using them) I even rigged up a way to have power buttons for each system in a small bank of buttons on the underside of my desk in the living room, but realized that I didn't use them very often so I removed them. Some of the computers have a bios setting that enable me to wake them when I hit the spacebar on the computer (if you really wanted to shut them off) I've been using this setup very easily for the past 1.5/2 years or so and have found that it cleans up and quiets down my living room. The crawlspace is also a little cooler which presumably is 'good' for the computers. Incidentally I don't have any speed issues whatsoever with remote desktop, and use it regularly and transparently on the network at work. (The settings to reduce the weight of the traffic on the network are easy to find by clicking the 'Options >>' button. Hope this helps

I also use visual studio for the majority of most days, and about 8 months ago, I had to write a justification for my boss to purchase dual screens for me (along with the associated card). I did a bit of research to see if I could find any substantial information (stats/studies, etc..) to support the idea of dual screens. After a bit of digging around I found one. http://www.humis.utah.edu/humis/docs/organization_951_1147817063.pdf[^] (The relevant section is on page 33.) After reading the justification, my boss couldn't wait to get dual screens, because of the relative low cost and potential productivity increases. You don't need to get humongous monitors since the price usually skyrockets per square inch as you go up past 19" or so, the numbers are likely more favorable to get more smaller monitors instead. I have to say that my experience entirely corroborates the claims from the study. The additional real estate has a valuable impact on the continuity of my attention. Task switching and 'window housekeeping' take up more time than ppl think. We have since obtained dual screens for all the developers in my team, and the project leader. I just found this on google too: http://research.microsoft.com/displayArticle.aspx?id=433[^]

Far side all the way. Though, I don't think Larson produces comics anymore, I have a 2007 desk calendar just the same, and the quality of his humour is excellent.

It's because of all the smoke moving around inside the cpu getting the work done. It's a little-known fact that all electronic equipment works using smoke. It is for this reason that when you let the smoke out, it stops working. ;)