Steve Eichert

What is the fastest way to dynamically instantiate an object?

Referenced Assemblies with CodeDOM

Last night I was working on a re-write of the base framework I've been using on a lot of my projects recently. Part of the re-write involved creating dynamic assemblies using CodeDOM. I made some good progress but ran into a problem when trying to reference assemblies. I used the CompilerParameters ReferencedAssemblies property to add each assembly but this didn't do the trick. When compiling the "code" I received a "Metadata file XXX could not be found." error. The dynamic assembly is created by the MyFramework assembly and is having problems finding the assembly of the MyProject assembly

• Customer object in MyProject calls a method on the object its inherited from (AbstractEntity) which is in MyFramework
• The AbstractEntity object in MyFramework should (if things weren't broken) create a dynamic assembly to perform some operations on the Customer object in MyProject when the method is called.
• When AbstractEntity tries to create the dynamic assembly it adds references to MyFramework and MyProject using CompilerParameters.ReferencedAssemblies.Add()
• A "Metadata file MyProject.dll could not be found" error is returned when compiling.

Any ideas?

RE: Fixed Bid Follies

Jonathan Goodyear just posted a very interesting article about stearing clear of fixed bid projects.  I've been thinking about this a good bit recently due to some of the outcomes of some fixed bid projects I've worked on in the past couple of months.  It seems that "we" (as service providers) too often force ourselves into fixed bid projects rather then trying to educate the client on how an hourly contract may be more appealing for both parties.  

In a post last month I talked about Agile development and how it can be applied to fixed bid projects.  I've come to the conclusion that it is possible to use Agile methodologies on fixed bid projects but doing so requires a lot more un-agile practices to be used in order for it to work.  I still do almost all of my side projects on fixed bid contacts but they almost all fall into the under 200 hour limit Jonathan spoke about in his article.  I'm slowly coming to the realization that I need to start changing my ways in order to provide myself and my clients with the greatest chance of success.  It isn't going to be easy but in the long run I'm sure I'll be more successfull because of it.

Is Storing images in SQL Server a good or bad idea?

Update: Check out the final results !

I just started on a little side project that is going to allow an administrator to upload documents through an administration tool.  On the public side of the site users will login to a members only area and be able to browse the documents.  I've decided to see how storing files in SQL Server will work.  I figure this is a good project to try it out on since its a pretty small app with a low user base.  I like the idea of not having to worry about configuration on the server so we'll see how it goes.  It looks like I'll have to alter some of my framework code to work with the byte[] data type. 

Anyone feel the urge to share any experiences with storing files in SQL Server?

What would my ideal entity object framework look like?

Let me start with a definition of what I'm calling an "Entity Object Framework".  In the world of object oriented developement we often create a set of objects to represent the "business entities" that make up our application.  These business entities have properties and methods that define who they are and what they do.  In almost every application these business entities need to be persisted to some sort of data store.  An "entity object framework" provides the plumbing for dealing with entities, as well as their persistence.  Rather then worrying about how to persist the business entities the developer should only worry about ensuring all the properties, methods, and object relationships are defined properly on the object.  The developer shouldn't have to write redundant code for persisting each type of business entity, it should all just work through the magic of the entity object framework.

What I'm calling an Entity object Framework may sounds very much like an Object Relational mapper.  In fact perhaps some day one of the OR Mappers (EntityBroker, DeKlarit, etc) will provide me with just what I'm looking for. 

In my ideal world I want to deal with objects, not DataSets, and not Xml.  Now that is not to say that the EOF shouldn't have support for DataSets or Xml, its just that in my world I want to choose to use them when and where they make sense for me, and the application I'm working on.  I must state that I haven't really given a pure Xml or pure DataSet (typed) based architecture much of a chance so perhaps that should be something I put on my long list of todo's.

When I'm working with my entity objects I want to be able to use a .Save(), .Delete(), .GetAll(), .GetByID() and etc methods directly from my objects.  I don't want to have to go through a data manager class, I don't want to go through a broker, I just want the objects (actually the framework) to handle these operations for me.  In my ideal world I want the object to not only handle it for me but to handle it for me without forcing me to write code.  I should be able to provide some meta data through some custom attributes that will allow my objects to figure out how to save themselves, figure out how to load themselves, and figure out how to give me all objects where a certain property equals a value I'm interested in.  I haven't totally figured out all the details of how a framework would handle all of this but I've figured out enough of it to know it can be done. 

Not only should my entity objects be able to figure out how to save, delete, load,