Hoping for some real gains out of Whidbey/Visual Studio

Published 09 October 03 10:19 AM

It's almost time for PDC 2003, and I have a lot of hopes for what I'll find in the presentations.  I work mostly in asp.net and while the framework has been an incredible improvement over my past web developement techniques, there are still some shortcomings.  Here is an off the top o' my head list of those things we seem to spend the most time with.

- handling events on dynamically loaded user controls.  This mechanism just doesn't work.  For now, we work around it by declaring the controls early so that viewstate picks them up and usually fires the events, but there has got to be a better way.

- lock dlls can't be overwritten - the infamous larger than 64K dll size issue where seemingly randomly, a project can't be rebuilt without closing the IDE

- 1 project = 1 virtual directory = 1 dll. Really a vs.net issue, but would really like support in vs.net to be able to have multiple dlls target the same bin directory, without separate projects.  One example would be to target a set of NUnit test dlls, that would not get copied to the server at release time.  I'm looking forward to hearing about the new build system.

- ugly html, non xhtml compatible tags.  Geez, why when you go into a designer does it remove quotes from attribute values?  Why must it muck with my html at all if I have that turned off?

- a managed vs.net plugin api.

- managed mmc snap ins

- a web service api that isn't so tightly bound to http and xml serialization.  It was a cool idea, but it seems like everytime I try to do something more advanced with the web services api, I hit a wall.  I want to pull web service requests off of a queue, out of an email account, off the file system.  I want to have a web service proxy that doesn't have the URI embedded so I can have a test and live version without recompiling the code.  Not all document oriented services make sense to turn into a Type that gets deserialized.  Take a look at some of the schemas in the financial world and you'll see what I mean.

- another bonus would be a clear voice product that can call out to services and service my VRU

 

I guess I'm just getting started...

by panmanphil
Filed under:

Comments

# panmanphil said on October 9, 2003 11:36 PM:
I think you will be happy with what you will see at PDC for item #7 ("a web service api..."). Also, there is already a way to "to have a web service proxy that doesn't have the URI embedded", just check make the proxy dynamic in VS. This enables the Url to be read from config. In addition, you don't need to process documents as CLR types -- you can just use the DOM or another of the Xml APIs with a [WebService] if you want.
# panmanphil said on October 10, 2003 4:19 AM:
Just to elaborate on douglasp's comment, when you change the proxy dynamic, you have the option of reading it from the config file (VS.NET puts the element in there as soon as you change the behaviour to dynamic) you can use URL instance member of your web service to set the URL as well.
# panmanphil said on October 12, 2003 7:59 PM:
Do you have any idea what you are talking about when you discuss the changes to the .NET WebService API? Web Services are built on top of .NET remoting. If you want to pull web service requests out of an email or off of a queue, try using plain old .NET remoting using a TCP transport. Perhaps if you had a better grasp of the technology you could make better requests.

The same goes with your 1 DLL virtual directory issue. If you want multiple assemblies, create the different projects within the same solution. What's the problem with that? Of course, I'm sure there probably could be some improvements made that would allow you to point different source files to difference assemblies within the same project, but is this really a HUGE issue when there are so many REAL problems to deal with?
# panmanphil said on October 12, 2003 9:58 PM:
This is regarding Joe's comment about WebServices being built on top of Remoting.

If I remember correctly, the XML serialization stacks for Remoting and Web Services are completely different. Also, the invocation of Web Service methods do not do through the Remoting channel / formatter / sinks stacks.

I am therefore hard pressed to understand exactly what the poster meant by Web Services being built on top of .NET remoting.
# panmanphil said on October 13, 2003 4:07 AM:
In regards to Joe's comments. I have actually dug pretty deep into the web service api's. As Atul points out, they are in a completely different branch than the remoting api's. The web service api is closer to what I need, the ability to serialize a request and distribute it in full to another process or set of processes. This is encapsulated in the SoapMessage, which as it currently stands is very tightly bound to the http implementation. From comments I have received, I will be pleasantly surprised by the new version.

The problem I have with one directory, one dll, has much more to do with problems of avoiding circular dependencies and organizing related code. Of course solutions are the supported answer and now I have dozens of them, each holding many projects. I already have a workaround, an NAnt based build system. However, I still like the idea of more flexibility into how my compilation units are broken up and deployed. And, this is a vs.net issue, not a .net issue so it remains on my wish list.
# panmanphil said on October 13, 2003 4:09 AM:
Thanks for the tip on the dynamic proxy!
# panmanphil said on October 13, 2003 4:27 AM:
Since one of these comments was a little abrasive, I just wanted to clarify the title. The title listed at pdcbloggers was theirs, not mine. Mine is the one in the blog. I suppose theirs was more sensational and based on the fact it has been the top post since last Thursday, they were right! But my title emphasizes hope over shortcomings, don't you think?

Based on comments from Microsoft employees privately, they understand the intent of the message and for that I'm glad. We have the joy of working with an incredible set of tools but even a very brief survey of our industry's history will show that we are just not there yet. We must constantly examine how we do things and try to improve.
Anonymous comments are disabled