These are my notes on the Hosting the CLR Panel. I will try to arrange them and make them more readable later on.
On the panel, Mahesh Prakriya, Chris Brumme, Sean Trowbridge, Chris Brown, Dimitry Robsman(ASPNet), Jose Blakeley(SQL), Mark Alcazar (Longhorn), and Thomas Quinn from Microsoft, and Andrew Murchinson from IBM (DB2).
Q : Chris brown, What is the hosting API ?
A : First, the original hosting environment had 11 pages to describe the APIs, the whidbey one is 106 pages long. It is made of COM interfaces to change the threading model, memory allocation, synchronization primitives, and other extensions to the regular interoperability methods ...
Q : Is IBM thinking of using an alternative implementation of CLR on its alternative plateform ?
IBM : The initial implementation is only for NT and thus will use the Microsoft Runtime. On next versions, We are thinking about Mono ...
Q : overhead on memory ?
A : overhead of several megs, ASPNET first app domain about 10 Mb on empty, subsequent around 1Mb ... Loader optimization to balance perf and overhead (single domain/multi app domains)
Q: Rule of thumb ?
A: single domain is faster for static, initialization ... multi domain, costs related to sharing and preventing side effects. Trying to make that better in whidbey.
Q: hosting 1.0 CLR. some client tried to use 1.1, and had problems. How to prepare for compatibility
A: office way, not have the config file (Clr version) makes the latest version load
in SQL, ASPNet, DB2 biding to the specific version for stability and dynamically choosing the version to load
Q: SP calling an object defined on the host (ex: reporting services, write a formula in .Net, calling a ref to an object exposed by the host) ?
A: SQL, is value based.
Fragments of the user code :
- state
Q: programming model for SQL is limited. programming models in the particular hosting scenarios will be different ?
A: hoping others will behave
Q: something like CLS ? or informal guidelines ?
A: not aware of any attempts to standardization.
Q: unamaged code hosting the CLR
A: if it is just to deal with memory pressure, GC ... large amounts of unmanged, relating to some managed objects, inside whidbey it is possible to link those to GC
Q: How about synchronization ?
A: depends on the level at which the sync is needed
Q: Rule engine
A: reflexion emit, use compiler and load the class from file. what level ? a compiler, higher level language, persistant store (laughs) ... like Store procedure or user defined functions. light weight code generation APIs if no meta Data.
Q: legacy Win32 app. Host CLR and start using managed ?
A: COM Interop ... or IJW - if multi-app domains, then maybe to think about it.
Q: Licensing issue for hosting the CLR
A: none.
Q: ISV doing it ?
A: will not speculate.
Q: created a managed COM object, and make it not appear in the default app domain (VS calling the add in)
A: Threading models issues... launch app domain, and call from it ... obviously no good answer (just inventive ideas). in the longhorn timeframe might be solved
Q: in office, is it one runtime per process ?
A: one runtime per process
Q: hosting API is not part of CLI
A: should it be ?
Q: hosting vs MCpp
A: com interop vs MCpp, MCpp is less cosly
hosting ? don't know exactely, but MCpp would look the way to go for less costs
Q: 120 pages can be scary
A: that stuff is used by SQL, not necessary to use all the interfaces
the v1 is what most apps will need.
hosting is really about extensibility and tuning how the runtime is used ...
DB2 created own class loader.
Q: ASPNet in addition to hosting CLR, has its hosting APIs.
A: app domains conveniently ...
Q: upgrading from 1.0 to 1.1 cused problems (regiis to get it back to old version)
A: taking it seriously, do not upgrade ...
Q: loading an assembly, what SQL does, what steps at creation, what steps at loading -is there NGEN
A: store user asemblies in the database. prefer to load from DB except those in GAC. intercept reference resolving and go get the assemblies (detach from database, attach somexhere else ...), CAS, well behaved and no conflicting parallel executions. At runtime, rely on runtime checks.NGEN not used (restriction to file system assemblies, ...
DB2 looks up asemblies in the file system.
Q: Porting to managed or hosting
A: SQL millions of lignes of unmanaged, impossible to upgrade in short or midterm. hosting gives the exetensibility needed.
Q: different localization processes ?
A: match locale of the DB
Q: CLR GC control. objects that are machine wide shared.
A: CLR self tunning. hosting can control GC. machine wide shared not feasible.
Q: serevr vs workstation CLR
A: workload.if MT, server can add perf. Workstation useful in uniproc.