Where's Movie line of the week?
Sorry folks. The holidays have messed with my internal clock a bit.
Movie line of the week will continue next week.
Steve Teixeira: "Using C++/CLI you can natively access the C-style API and provide a .NET interface on top of it that is directly consumable by C# (or any other CLR language). This is the preferred method if you have to work with a lot of functions/types because it's type safe, less error prone, and more maintainable. It's also pretty much your only option if your API exposes any native C++ objects." - This is something we're going to have to tackle at work. We're a cross platform C++ shop and we're doing some client side work(Win32 only) using C#. I think Steve has given about the best advice he can in this instance, but I'm guessing the gentleman he's giving the advice to doesn't have the requsite skills to pull off the recommendation. Alarms sounded in my head when I read "I am a VB turned C# developer..."
I've written C# code using P/Invoke and it does indeed work quite well, but I wouldn't want to wrap up TONS of C/C++ code using it. This is, I believe, a perfect case for a mixed-mode assembly; written in C++. There's a good chance it's going to be quite messy on the inside but properly designed will provide a very nice managed interface to both your unmanaged C/C++ and Delphi code. One assembly could provide 'interop' classes around the old-school C code and Delphi code. I say it could be messy because of the hodgepodge of syntax sugar necessary to talk to both sides. Having said all that I can state, emphatically, I like doing stuff like this. Psycho, yep I'm bit psycho. I like seeing things work and on occasion that means creating elegant interfaces to disperate systems. From my point of view as long as it provides a usable interface to the developer, is solid, and does what's expected I can live with the ugliness inside.
As time goes by, and .NET becomes more popular, companies will begin to provide PIA's to their old code and we won't see these types of discussions. Unfortunately we have to live with the tangle of code written over the years. Someday, maybe someday, we'll all come to realize dynamic languages(Smalltalk, Ruby, Python) are a better choice for future development, and our sanity. Until then we'll have to put our heads down and get stuff done.
Python for .NET
Jim Hugunin: "This release marks a major milestone in that we think we have workable answers to all the major design issues for a 1.0 final. " - Congratulations to the entire IronPython team. A great Python implementation on .NET is important in the evolution of the CLR.
Bring on more dynamic language implementations! Ruby is the first on my list.
Tulare County Autism Resource
A friend of mine I haven't heard from in a while dropped me a quick e-mail the other day to let me know what he's been working on. He's been involved for a while now helping autistic children. As a part of that endeavor he's created an Autism Resource website for Tulare County/District Special Education Local Plan Area(SELPA).
It looks great, but beyond that it's going to provide parents, teachers, and aides with invaluable Autism insights!
Great job Paul!
Tip for Nick
Hey Nick, I've found something you should take a look at. This site should explain how to host the .NET CLR inside your Delphi application.
Good luck, and get us IBlogExtension support in the next release.
Here's a quick how-to for building IBlogExtension plugins for RSSBandit. Those plugins will work for FeedDemon as well once you have support in place for IBlogExtension.
Help using ClrCreateManagedInstance
I'm stumped. I've been trying to use ClrCreateManagedInstance to instantiate System.Reflection.Assembly but it always throws an error of 0x8013151a. In the book .NET and COM, The Complete Interoperability Guide it states on page 469 "The string passed as pTypeName must be an assembly-qualified class name unless the class is defined in the mscorlib assembly." That's the ONLY clue I have to this problem. System.Reflection.Assembly is indeed a part of mscorlib. Does that mean I'm outta luck, or is there something special you have to do to use classes exposed in mscorlib?
Here's the code...
static const wchar_t* stc_SYSAssembly = L"System.CodeDom.CodeObject,
//static const wchar_t* stc_SYSAssembly = L"System.Reflection.Assembly,
static void testDotNet(void)
IUnknown* p = NULL;
hr = ::ClrCreateManagedInstance(stc_SYSAssembly, IID_IUnknown, (void**)&p);
p = NULL;
} // testDotNet
Running this code using the line stc_SYSAssembly pointing at System.CodeDom.CodeObject works just fine, but changing it out to the line below that points stc_SYSAssembly at System.Reflection.Assembly fails.
Am I going to have to create an instance of CorRuntimeHost using CoCreateInstance and go from there?
Any help appreciated.
Happy New Year!
Here's wishing you a happy and prosperous 2006!
2005 was a strange year for me. I began the year unemployed, which is not a great position to be in. In March I started a new job with Pelco and began developing full time in Linux, which has been quite an interesting ride after spending the last 15-years as a Windows developer.
We were blessed in 2005 in many ways and for that I'm very grateful.
Bring on 2006, it's gonna be a heck'uva ride.