[From Sam Gentile’s Blog]
Here is a direct link provided by Sam Gentile. Don’t know if it works with Beta 2, but we can only hope!
Can anyone confirm this yet?
[From Doug Turnure]
David Chappell is going to be delivering a presentation on Indigo at the Microsoft Campus in Alpharetta on April 18th. Doug says to get there early though!
http://www.microsoft.com/mscorp/info/usaoffices/southeast/alpharetta.mspx
Understanding Indigo
Indigo is the code name for Microsoft's new foundation for distributed computing and service-oriented applications. This presentation provides an introduction to Indigo, describing what it is, how it works, and how it fits with existing technologies like ASP.NET web services, .NET Remoting, and Enterprise Services. While some familiarity with .NET is assumed, the target audience includes anybody who's interested in how software development will look in the coming service-oriented world.
And here's a short bio:
David Chappell is Principal of Chappell & Associates in San Francisco, California. He has been the keynote speaker for conferences in the U.S., Europe, Latin America, and the Middle East, and his books on enterprise software technologies have been published in ten languages and used regularly in courses at MIT, ETH Zurich, and other universities. David's consulting clients have included HP, IBM, Microsoft, Target Corporation, Stanford University, and others.
It was a great meeting with Microsoft opening up 3 rooms for all the people last night. They covered a lot of material in the amount of time allotted! Kirk Allen and Jerry Dennany list some of the stuff covered, but if you missed it, you really missed a great meeting. Brendon Schwartz and Matt Ranlett (Atlanta .NET Regular Guys) have posted something as well. Man, these guys goes to almost every user group meeting in Atlanta and shares lots of information on their blog. (thanks guys!)
What I thought was real interesting was the stuff about performance enhancements to System.Reflection. I don’t see a lot of documentation about it yet, but I guess there is a way of caching a unique token that you get from something like MemberInfo and then be able to get the MemberInfo back using the token. I will post more info after I investigate it more…
If you have never attended an Atlanta C# User Group meeting, tonight would be a great night to start. (I know you reading this Brian, so consider this your official invitation 
)
Several members of the CLR team are going to be speaking at tonight's Atlanta C# User Group meeting.
Included in the lineup are:
Brad Abrams - Lead Program Manager, Common Language Runtime team
Kit George - Program Manager, Common Language Runtime team
Claudio Caldato - Program Manager, Common Language Runtime team
For more information on this month's meeting, please visit the website at:
http://www.atlantacsharp.org/NextMeeting.aspxIf you are not familiar with the meeting location, please print out the driving directions on our website for reference:
http://www.atlantacsharp.org/MeetingLocation.aspx
As you may or may not know, the method AppDomain.AppendPrivatePath has been marked as obsolete in the 2.0 framework. The message is this: "AppDomain.AppendPrivatePath has been deprecated. Please investigate the use of AppDomainSetup.PrivateBinPath instead.". This is the method used my most applications the use a module or plugin style framework to load their assemblies. The problem now is that it’s replacement of sorts is to use AppDomainSetup. AppDomainSetup can only be used when setting up an AppDomain and before any assemblies are loaded. Thus if you need to dynamically load assemblies from an a directory other then the one containing the executable, you are in trouble.
Some options are using the Assembly.LoadFrom instead of AppDomain.Load or Assembly.Load. This has a whole new set of issues that you have to be aware of as well.
What are others doing to migrate old or create new plugin type applications?
Here is a quote from a
bug report on MSDN,
| Opened by drieseng on 2004-08-30 at 11:22:24 |
| |
In .NET 2.0, the AppDomain.AppendPrivateMethod is marked obsolete (with message "AppDomain.AppendPrivatePath has been deprecated. Please
investigate the use of AppDomainSetup.PrivateBinPath instead."). However, AppdomainSetup.PrivateBinPath is not valid alternative, as you cannot use the PrivateBinPath property of the AppDomainSetup to modify the privatebinpath for a domain that's already created. Modifying the PrivateBinPath property does not have any effect on an existing domain.
I've attached the source code of a small test application that modifies the privatebinpath of a newly created domain using the AppDomainSetup.PrivateBinPath (as recommended by the obsolete message of AppDomain.AppendPrivatePath). The sample app will demonstrate that you can use AppDomainSetup.PrivateBinPath to set the privatebinpath for a domain that you're going to create, but you cannot use AppDomainSetup.PrivateBinPath to modify the privatebinpath of an existing domain. |
| Resolved as By Design by Microsoft on 2004-08-30 at 13:50:15 |
| |
Yes, this is intentional. The point of deprecating it is so that an appdomain's binding context can't be modified after assemblies have been loaded. Providing an alternative which allows that would defeat the purpose.
This is required for domain neutral assembly binding. Apps using this method should use AppDomainSetup.PrivateBinPath instead, at appdomain creation time. It was never intended that AppendPrivatePath() be used to append paths after assemblies have already been loaded. If that is desired, a new appdomain is recommended. |
