Entity Framework and Views.. Too many keys on the keychain…

I am currently working pretty heavily with the Microsoft Entity Framework for .NET. I just ran into a nice quirk in the Model Wizard for Views.

Well, it seems the model wizard is not able to intelligently determine the primary keys for a view so it resorts to deciding that any NON NULLABLE field must be a primary key. Retarded…yes.

So how to fix this? Well, as long as you don’t mind never using the wizard again you can go in and remove the entity key flag off the conceptual model fields and then delete the key references on the storage model. This all in the XML editor naturally, because of course you can’t do anything useful int the modeler.

Note: Once you fix your keys, if you rerun the Model Wizard to import/refresh tables, you will have the pleasure of hand editing the file again for all your views.

Will this be fixed in 4.0? We will wait and see

Where did that Visual Studio 2008 menu go….

So I was working in Visual Studio had a hankering for debugging an already running process. Easy right? Debug -> Attach to Process. Well, it’s not so easy to do when the menu option dissapears. I pulled up my Debug menu and it had 4 options. Windows, Start,Step Over, Step Into. Hmmm.. missing something there right.

Well, after pulling a few hairs out I figured out how to get my Attach to Process option back.

Its painful but effective. Tools -> Import and Export Settings. Reset to Visual Studio default. Pick the best generic settings and finish the wizard.

All your menus will be back to normal. You just lose all of your keyboard shortcuts and custom settings you painstakingly setup.

.NET Illuminator v1 Alpha Released to the wild

So….I finally decided to release my alpha version to all you hooligans who want to see whats under the hood of fellow .NET’ers applications. You can use .NET Illuminator to see all the UI objects in another .NET application and even manipulate them. Yes, pretend like you are in Visual Studios Form Designer and just start viewing and changing properties.

You can also view all connection strings the application has used to any SQL  servers.

I will post more when I add more.  Happy hacking!

Click here for .NET Illuminator Page

Let’s all jump into the pool..The SQL Connection pool that is..

I was out swimming in the data pool and I started thinking to myself, how many people are sharing the same pool without me even knowing they are there? How did I even get into the pool? And why is the water so cold?

Well, if you are using ADO.NET with SqlConnection , you are playing in the pool to. ADO.NET is a pretty smart animal. It realizes that if you are going to be connecting to a database a lot, then its probably a good idea to keep the connection to the database server open awhile. It does this behind the scenes, so when you create multiple data connections, it only really grabs one from the available pool of connections and uses those.

So….with that in mind, I started thinking about how I can tell what data connections an application has used and who is swimming in my pool. Coupling that with the brainstorming involved in .NET Illuminator, I came up with a very nice and simple piece of code that grabs all the connection strings from the Pool and throws them in rafts for you to see.

Why might this be handy for .NET Illuminator, well…Its always interesting to see what data connections an app has made and what the connection string is for them 🙂

Here is my simplistic example of using C# with .NET to walk the SQL pooled connections and return their connection strings.

         /// <summary>
        /// Loads all pooled connection strings.
        /// </summary>
        /// <returns></returns>
        public static List<string> LoadAllPooledConnectionStrings()
                SqlConnection connection = new SqlConnection();

                FieldInfo connectionFactory = connection.GetType().GetField("_connectionFactory", BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Static);

                object cFactory = connectionFactory.GetValue(connection);
                FieldInfo connectionPoolDictionary = connectionFactory.FieldType.GetField("_connectionPoolGroups", BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Instance);

                object dictPools = connectionPoolDictionary.GetValue(cFactory);

                Type poolDictionaryType = dictPools.GetType();
                PropertyInfo pooledKeys = poolDictionaryType.GetProperty("Keys", BindingFlags.Public | BindingFlags.Instance);

                object keys = pooledKeys.GetValue(dictPools, null);

                List<string> allKeys = new List<string>();
                foreach (object key in (IEnumerable)keys)
                return allKeys;
            }catch(Exception err)
                throw err;

So…What did we learn? Just because you don’t see the pool….smell the chlorine…or even get wet, you open a data connection and you have jumped all the way in.. and left your stench behind in the water..

Happy swimming!

System.Diagnostics.Stopwatch is no longer my friend….

So..I have been thinking for quite some time, “Gee, wouldn’t it be nice to have a nice and easy to use timer class built right into the framework?”. I decided to go and use the lovely Stopwatch class to start building a lot of timing routines into my applications for debugging and logging purposes. The syntax was so easy and beautiful.

var sw = new System.Diagnostics.Stopwatch()

Can’t get much simpler than that, right? Well…..that is if the stopwatch returned reliable results….

It seems on one our computers we run this code and a 23 second process returns 10.5 seconds…Yeah, same thing I thought.. What a bunch of crap!

So, I read something about Processor Affinity and CPU clock stepping that may be causing the issue. Either way, I don’t want to have to set the threads processor affinity or try and manage the CPU’s frequency just to take a simple time measurement……Back to the old

DateTime start = DateTime.Now();
TimeSpan elapsed = DateTime.Now() - start;

I know…not much difference, but didn’t the Stopwatch look so much cooler?

Do I need a shot because I am thinking of an Injection?

I began thinking more and more about writing an application that is able to “illuminate” another .NET process. Basically, I want to be able to inject some code into another .NET application and then provide the ability to see all of the user controls and Forms loaded in the application as objects that can be manipulated.

I am working on creating the application that will shove itself in there and let you see every active control and Form and let you manipulate the properties of them all realtime. Make the button active. Show the hidden panel. Change the text on a label for your own amusement.

It should be ready in the next few days, so stay tuned for .NET Illuminator…