October 2004 - Posts
I just came across an interesting site , C-Sharp Source that acts as a library of links to different .NET tools. Check it out. You are bound to find some interesting ones hiding there.
I didnt realise there were AOP tools available for .NET. I am planning to look into some AOP stuff to reduce the instrumentation and tracing burden on my code especially when I have to write the usual "Method [X] Entered" , "Method [X] Exited" etc. I saw an article somewhere that deals with this (Using Attributes for AOP or something like that ) . Must try and dig it out.
I should also pick up log4net and use that in the next project. I've heard a lot about it, but never got round to using it. Currently I have a custom component that does the logging. I looked at the Logging App Block and found its rather huge and all encompassing. I'm not sure I need all that power, but its good to know its available for use.
Got quite a few responses to my earlier post about the alleged forthcoming demise of the Registry. Instead of just replying on my own thread, I think its worth creating a separate post for this.
In reply to the comments on config files being the INI files i referrred to, actually i was referring to WIN.INI and SYSTEM. INI. At least they were centralised, which is more than can be said for config files (especially if there is shared information)
Basically, I think config files are fine, but they can become very unwieldy especially for DLLs that have a large number of calling apps. <xyz>.DLL.config does not work. Some people have written on other sites that they have managed to make this work, but i dont believe it. Either it works for everyone or it doesnt.
In my current project , I have a big DLL with lots of functionality and most of my settings are in the Registry as there are web services, console apps and windows apps that consume this DLL and Im not going to replicate common config info across all those app/web config files. It would be a nightmare to maintain.
As it is I'm using the EMAB and every client app has to have the EMAB configuration info held in its config file. I havent taken the step of customising the EMAB to read from the registry yet, although I think that will have to be the way forward, or else I have to put all config data on to a standard place (say, Program Files / Common) and read from there.
I had other problems when I tried to put multiple custom config sections in my config files. It just didnt work. I read a ton of articles on the net but none of them were useful. I had exceptions thrown all over the place. The NVC reader would read from the first config section but would stop there and not read further. Thats why I just threw all that away and stored the data in the registry.
Another thing which is beginning to bug me is that I have lots of NUnit test projects (for the various components of the solution) and they have ended up sharing some common config info retrieval. Since they are all console apps, i have used config files, but the replication is annoying. I am not sure if I should abstract the config info into one place and have all the test projects use this common TestDataRetriever component. After all, tests are supposed to be independent. Or is the independence only meant for individual tests and not for test projects ? How do the other folk on this forum manage large test projects?
I was told by a colleague recently that MS is planning to scrap the registry as its becoming unwieldy. Is that true ? Or is it just a dodgy unfounded rumor?
Whats going to happen if they really do that and more importantly when ? (My latest component uses the registry extensively, so I have a personal stake in the matter !!) And whats next ? Back to the old INI files in the Windows folder ? Or some newfangled thing in WinFS ? If its the last one, then we can breathe easy cos that aint going to happen any time soon (See my post for the great cop-out here. Some pretty lively discussions went on in that post too)
Hoo boy... I thought it was getting round to the season to be jolly but it looks like we are some way from that now!! Feathers have been flying on some of the posts about DNN here on this blog and I'm rather embarassed about having started it all in the first place.
It ain't been all smooth sailing for me personally too. Some looming critical deadlines and some missed ones have seen me losing sleep quite a bit. I've got a long list of things to post about, but never seem to have the time to write 'em up.
Amazon UK isnt helping either. I ordered some books from them ages ago and they still havent arrived. It was supposed to arrive by next day shipping and considering its local to the UK, it beats me as to why they still havent arrived. There's a C# Design Patterns book in the collection (not the James Cooper one). Actually the James Cooper book did recieve some bad press on a particular site. I cant recollect which one off-hand but the reader was quite detailed when he took it apart. Anyway, hope this one is good.
On to the subject of patterns now. There are plenty of sites with articles that discuss patterns but all of them (that I've seen) take the route of discussing animals and animal behavior (ie) bark is polymorphic depending on the type of dog and all that. I absolutely detest such explanations. How many developers here are building applications for dogs and cats ?
I'm quite surprised that even MSDN only has a couple of detailed articles dealing with Factories and MVC. But then again, i just remembered that they do have the Enterprise Solution Patterns book with a comprehensive treatment of various topics. Goodness, I must be getting old. I nearly forgot about ESP. :-)
Ciao!!!