Archives

Archives / 2004 / July

  • And Another Thing...

    No Comments

    While I'm updating wish-lists I'd like to add something to this list: more control over web reference proxy generation. I understand that this may in fact be solved by VS 2005's new web services tools, but on the off chance that it isn't I'd like to get this out there.

    Our latest application uses web services for the entire data layer. This means that 90% of the business logic and all of the database communication is handled by a web service (really it is handled by a number of web services due to the size of the application).

    One of the issues we've run into is in managing this. We want to maintain a single assembly that houses all of the web references and associated helper classes. With a large number of class libraries and executables this saves us a ton of time and it system actually works pretty well. We have AppSoap.dll that holds the web references and a few other classes and this is in turn referenced by a dozen or so other assemblies.

    But there is one issue, the proxy generate builds the reference.cs and gives a number of items an “Internal” protection level. This means that while we can reference <namespace>.<typed dataset>.<typed datatable> we cannot access the column names in that dataset.

    The sort of it: either keep it all public so I can reference my web services anywhere I need to or give me control over it. Right now I have to search and replace “Internal” with “Public” every time I update the web service. Yuk...

  • Updated Wish-List

    No Comments

    Now that we are half-way through 2004, I thought I would take a look back at my New Year Wish-List and see how far we have come.

    ·         To have the C# team come to the realization that Edit & Continue is in fact not the devils playground. Maybe they don’t make typos but I sure do (some 10 in the post alone I bet). Having to restart the entire application to fix a single letter is a massive productivity killer. Edit & Continue, it is your friend.

    This one may require sending foul smelling fish products to the C# team's office.

    ·         For someone to finally unseal the ImageList component. Or at least implement the ImageList as an interface so we can develop our own. For those of us who build commercial apps with hundreds of windows this is a huge issue. Someone decides that the “New” icon should be changed and we spend the next week changing it in 99 places (yes, 99. Because we always forget to change one someplace).  Hell, think of the memory savings that could be had by only having a single global ImageList rather than 100 separate ones with 99% of the same images in them.

    Hmm.... I may have to stock quite a bit a foul smelling fish products.

    ·         A real source code control system API. See that one that you have now? Give it too Frodo and send him to Mt. Doom right away. It is evil and needs to be destroyed. Source Code Control is the most overlooked aspect of software development and the poor API support provided by Visual Studio is doing nothing to help correct it.

    While it is unclear what effect the new SCC system from Microsoft will have on the exposed API, I suspect it will improve things quite a bit. So it looks like this one will actually happen.

    ·         Yukon by Q2

    Yukon by Q2 2008? OK, that is unfair. SQL Express at least shows that progress is being made. Maybe by early Q4 then?

    ·         Someone to confirm that there will in fact be an MSDE version of Yukon. I always assumed so but someone pointed out that this has never been explicitly stated.

    100% answered by SQL Express. Congrats to the Express guys by the way. I really like what I've seen so far.

    ·         A [Replaced] attribute that goes one step beyond [Obsolete] in that it causes Visual Studio to automatically replace the old reference with the new reference. The best example is with property values persisted in the InitializeComponent method. When you
    ”Obsolete” a property Visual Studio doesn’t remove the old reference so you get a slew of compiler warnings that you must then delve into generated code to fix. This is even worse if you actually remove the property all together. It would be nice if the system could handle this automatically and use [Replaced(NewFunctionName)] to point to the new property.

    No idea. Someone hinted to me back in February that an answer to this problem was coming with VS 2005, but I've not seen it.

    So we have a 1:6 ratio. Considering I've yet to loose a pound, stop smoking completely, or pick up jogging I would have to say that my wish-list is doing much better than my resolutions.