Jaa

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

  • Artikkeli

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.

Comments

  • Anonymous
    March 09, 2005
    I want to know the big picture on things. What is the vision here? The end game? This is some good stuff!

  • Anonymous
    March 09, 2005
    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

  • Anonymous
    March 09, 2005
    Some samples on using ACL related class libraries?

  • Anonymous
    March 10, 2005
    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.

  • Anonymous
    March 10, 2005
    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.

  • Anonymous
    March 10, 2005
    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..)

  • Anonymous
    March 10, 2005
    The comment has been removed

  • Anonymous
    March 10, 2005
    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).

  • Anonymous
    March 11, 2005
    CodeDom and Resources would be great topics.

  • Anonymous
    March 12, 2005
    The comment has been removed

  • Anonymous
    March 13, 2005
    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.

  • Anonymous
    March 13, 2005
    The comment has been removed

  • Anonymous
    March 14, 2005
    A lot of great feedback on Net Classes stuff here, that's good to see. Here's a comment on Eric's post above. The feedback comes from Dan Roth, the Program Manager for the Net Classes:
    "Using inheritance to fine tune method signatures sounds like a fine idea to me. We don’t provide the derived types, but users can easily create them themselves. In many cases though, it is convenient to just take a Uri as a parameter so that the APIs is easily extended to new URI schemes. For example, WebClient takes advantage of this. You can specify an HTTP, FTP or FILE URI to WebClient and it will handle them all seamlessly.

    The SecureString idea for credentials embedded in a URI is particularly valid if Uri instances are frequently being persisted in memory. We will consider this idea for a future release."

  • Anonymous
    June 02, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=54189

  • Anonymous
    June 08, 2009
    PingBack from http://quickdietsite.info/story.php?id=3104

  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=2738