BCL, Blog Day! Tuesday 3/15/2005 (next week) [Kit George]

BCL, Blog Day! Tuesday 3/15/2005 (next week) [Kit George]

  • Comments 20

A heads-up all. The BCL has a chance next week to provide some added value, and we thought we'd keep as the focus, making a number of blog entries and samples. We'll hopefully see a great range of topics pour forth from this blog next Tuesday, so keep your eyes on this spot.

Now is your chance to let us know what kinds of blog entries, and/or samples you want to see from us, so feel free to post your favorite question on the BCL in response to this entry, and we'll see if we can't get to it sometime on the day. The kinds of suggestions we're looking for will be pretty short (don't ask us to make a blog showing how to host the CLR, or make a completely optimized Set collection) so we can kick out a few issues, and will encourage a bit of explanation on our part, so it's more than a one line response. See you then!

Note: more involved samples may not be posted on that day, but do expect to see them 2-3 days after the event. And if you happen to ask for something we don't get to, just ping me at kitg@microsoft.com, to make sure we have it on our future blogs list.

  • I want to know the big picture on things. What is the vision here? The end game? This is some good stuff!
  • how about some stuff on Thread Synchronisation I don't really understand what the differences are between the different waithandle derivatives or in what circumstances you would use one over the other

  • Some samples on using ACL related class libraries?
  • I'd love to see tips on how to identify how much memory is being used by an appdomain in a multi-appdomain scenario (like asp.net). This would help when one of the appdomains has some sort of memory leak and we need to know which appdomain that is.
  • Thanks all for the initial suggestions, keep 'em coming.

    David, in relation to "I want to know the big picture on things. What is the vision here? The end game?", I'll assume you're talking about Whidbey. Let me know if that's not the case: kitg@microsoft.com.
  • Since you guys know 2.0 inside and out-- and we don't-- I vote for these topics:

    If you had to pick one, what is the single most important feature in 2.0 that developers should be experimenting with and exploiting as soon as they get their hands on it?

    What features in 2.0 *directly* address specific problems you've see in average developer code written in 1.0? In other words, how is 2.0 going to keep me from making the same stupid mistakes? (or at least encourage me not to..)
  • FxCop, which we've been using for the last six months while developing a library, tells us to use System.Uri for any URI-like argument. That's fine, we've been doing that; however, we've only recently found that System.Uri doesn't support our schemes (sip, sips, tel, etc. VOIP stuff) out of the box. It only parses the scheme, so something like uri.UserInfo returns empty or null.
    I've looked at .NET 2.0 to see if this has changed and it hasn't. However, I've noticed that there is now a UriFactory class which I assume is a means for extensibility. So I have two questions: 1) why doesn't System.Uri parse any uri that is compliant with RFC 2396(or better yet RFC3986), regardless of scheme? 2) How does the new UriFactory work?
  • Unloading Dlls.

    Yes, of course I know that the CLR doesn't support unloading Dlls as such, but everywhere that is mentioned, it is said: use AppDomains. But I have yet to see an example that demonstrates this use of an AppDomain. An example that shows the pitfalls you will stumble across when trying to implement it, such as the 300 second default timeout on cross appdomain calls on MarshalByRef objects.

    For example, look at the following scenario.

    The user, who knows how to write C# code, sees a trivial windows forms application that shows a textbox where he can edit some code that can be run from the application (for instance, require that the user's class has a method 'string Run(string)'; feel free to take your favourite approach to enforce this - a base class, and interface, or reflection). The form has two buttons, 'Compile' and 'Run'. Hitting the compile button compiles the code, creates an AppDomain, creates an instance of the user's class in that AppDomain, ready to run. Hitting the 'Run' button runs the 'Run' method that was defined by the user on a user-supplied string, and shows the result somewhere.

    Now the tricky points:

    - If the user edits the code, and hits the compile button again, the class (whose name has not changed - this is the core of the problem) should be recompiled and this recompiled version should replace the earlir version. As far as I see, to make this work (assuming that you don't want the old version hanging around), the old appdomain has to be torn down (to unload the dll compiled earlier), the new dll has to be compiled, and loaded in a new AppDomain.

    - Show how to handle the case where after hitting 'compile', and a new appdomain has been created, and a new instance of the new class has been created in that instance, the user hits the 'Run' button, *takes a 10 minute break*, and hits the 'Run' button again. In case you don't see the problem: the lease on the MBR object used to communicate between the main appdomain and the dynamically created one has expired by then - so the question is: how to prevent that, in real world scenarios. That is: how to correctly use ILease and everything related, in a cross-appdomain scenario (most MSDN documentation on ILease and friends assumes a cross-machine scenario).
  • CodeDom and Resources would be great topics.
  • > Unloading Dlls.

    I second that.

    I am working on a realtime 3D application that generates assemblies on the fly. Quitting the app every ten minutes to kill off dead types is not pretty!

    A cannot afford the hit of communicating with a second app domain, and even if I could, I dont want to have to flush out *all* loaded assemblies just to remove a few dead ones.

    If some sort of Assembly.Unload() were to exist, I would be perfectly happy for it to fail if there are any live objects, or types dependent on the assembly in question.

    So my question is, are there any plans to solve this problem in the near future?
  • Jason Kremp brings up a topic dear to me: the "IN-extensibility" of the built in Uri class.

    The implementation of it isnt the best-thought out, but you guys get a pass because of all the other great thinking that went into Framework v1.0.

    Personally, I'd like to see the the System.Uri revisited, possibly with some minor changes, like
    - specialized derivates of System.Uri, like HttpUri class that inherits from Uri: goal is to refine the "Type" (or scheme i guess?) of the Uri that a method might be expecting.

    WebBrowserControl
    {
    public void Open(System.Uri.HttpUri uriToOpen);
    public void Download(System.Uri.FtpUri uriToDownload);
    }

    Also, (although IE has completely disabled support for embedded logins to Uris) consider using SecureString for Uris that might support a username/pwd type of specification in the scheme. Like Http allows for http://username:password@domain.com/asdf

    PS: KitG: i had complained about "internal protected" methods, apparently that was a framework v1.0 compiler issue that seems to have been fixed.
  • Another thing that would be nice would be a somewhat standardization via the BCL of Protocol specific handlers and the exchange of (somewhat standard) electronic messages.

    System.Net.Mail.MailAddress is a great start to standardizing all the 3rd party components that accept an email address as a type, but I would like to see a little more accomplished, like a standardized IEmailMessage interface of sorts.

    The great thing about that would be to allow us to plugin various 3rd party components into our own frameworks without baking the 3rd party types directly INTO our frameworks. Perfect definition of BCL / System frameworks.

    I look forward to seeing / hearing a response to this one ;-)
Page 1 of 2 (20 items) 12