E12 and .NET Interop Questions
Scottie_do
how I write my code?
Does E12 use the ESE? Or will it using a SQL back end? Are they merging
into one technology?
Also, I looked all over this site for a thread that Steven Griffin mentioned
(in "Replacement for CDO/MAPI") for the technical reasons why .NET and CDO
won't work well together. Last time I spoke to PSS, I got the response "the
language team said it would work, and the CDO team said it won't." Anyone
have the actual link to the reason why this won't work?
I just hope that I'm not creating issues for my clients by not completely
understanding any issues that can be exposed by pinvoke.
And finally, can I use Managed C++ (perhaps in unmanaged mode?) to interop
with CDO?
Thanks~
lamont
(at)
dcpromo
(_dot_)
com
Stephen Griffin [MSFT]
Technical reasons - we're not really under any obligation to provide
technical reasons. Suffice it to say we've investigated a number of issues
resulting from using MAPI/CDO in managed code and made the business decision
that we will not provide technical support for it. You use MAPI/CDO in
managed code at your own risk. This is ground I covered thoroughly in my
previous posts.
Note that I say managed code - that includes managed C++. So the answer to
the last question is that Microsoft will not support it.
"Scottie_do" <Scot...@discussions.microsoft.com> wrote in message
news:E0C70562-31E7-4B67...@microsoft.com...
Scottie_do
COM objects (In MTS and other places) and are migrating to managed code. I
want to learn about what potential issues they will/could have. I searched
for your older posts and either they are not accessible from this web GUI, or
I didn't come across it yet. Nevertheless I'll keep looking. If only I
still had access to Visual KB...
I've never used Managed C++, so my understanding is that my supported
choices include either using C++ from Visual Studio 6 with CDO or go the MAPI
route and use unsafe code.
What are your thoughts about using a MAPI / C# combination? Is that a bad
idea? Would you think there would be a drastic difference in performance
when compared to C++?
Thanks for monitoring this newsgroup.
-cjl
Stephen Griffin [MSFT]
them. You can use them to write unmanaged C++, where MAPI and CDO is
supported.
My thoughts on using a MAPI/C# combination - very bad idea. It's the sort of
thing that'll mostly work. It'll work while you're writing it. Then it'll
work while you're testing it. It'll work while your customer is evaluating
it. Then as soon as the customer deploys it - BAM! That's when it'll decide
to start having problems. And Microsoft ain't gonna help you with it, since
we told you not to do it in the first place. :)
"Scottie_do" <Scot...@discussions.microsoft.com> wrote in message
news:9590A758-46F4-4BB9...@microsoft.com...
Scottie_do
unsupported with .NET. I will use unmanaged code.
Then if I wanted to allow managed code to call my unmanaged C++ code which
then calls MAPI,and as long as I have my threading OK (I heard there were
apartment threading issues) then I'm supported?
Thanks for clarifying
-Chris
Stephen Griffin [MSFT]
run your MAPI code in an entirely unmanaged process.
"Scottie_do" <Scot...@discussions.microsoft.com> wrote in message
news:BD030907-A7E9-408F...@microsoft.com...
Russell Mangel
http://download.microsoft.com/download/6/9/6/696C1E2F-AB3C-46C9-895C-CFCE7EA281EC/DAT316_PDC.ppt
From the limited information (written by overpaid non-technical marketers)
in this .ppt file. It appears that if you are a web programmer using 800ms
roundtrips to author and collaborate over the Internet using Exchange you
will be thrilled. However, if you are a LAN / Intranet programmer and you
use the new API's for heavy duty processing, you will be dis-appointed
because you will be sending and receiving your data via (bloated XML), which
is pushed through an IIS server running Web Services. I can't imagine how
this solution can be efficient. This especially bothers me because the CPU
manufactures have run out of CPU clock cycles. Hard Disk manufacturers have
given us enormous space, but Hard Disk performance has not increased
proportionally.We as programmers have to do more, with less CPU processing
on huge but slow Hard Disks. How can we do this when our API's keep getting
additional layers. <warning sarcasm head!> I wouldn't be surprised if the
Exchange Databases were just large XML files.
I spend most of my time getting data out of Exchange Server. Microsoft has
made in quite simple to put small amounts of data into an exchange server.
However, it costs a fortune to keep 500 GB Exchange databases available and
in good health. We have found the only way to avoid this is to remove data,
and place older messages in an SQL server where we can handle 500GB of mail.
It is far easier to manage 500GB+ SQL server databases, not to mention that
we can search much faster.
<Does E12 use the ESE?
From all of my research on the net during the past year, has revealed that
the MAPI property store will be retained in E12. Which means MS scrapped the
idea of using SQL server for the backend. The existing Outlook clients uses
the MAPI store extensively and this is most likely why Microsoft could not
easily remove support for the MAPI.property store (ESE). If you look back at
the history of Exchange Server, you will find that Exchange Server was way
off base (regarding the Internet) during it's initial development
(1994-1996). Of course this is hind sight, but if Microsoft could turn back
time and re-develop Exchange during those years. The MAPI property store
would have never been created. The database should have been written using
"Internet Standards" as the Mime Store, which eventually came in Exchange
2000. But by this time Microsoft made a smash hit with "Outlook" and Outlook
loves the MAPI store. So what do you do? Pretty simple, spend millions and
make both databases work together. Given enough power or energy anyone can
make a "rock fly".
<And finally, can I use Managed C++ (perhaps in unmanaged mode?) to interop
with CDO?
Yes (but don't tell anyone I told you this), and No. No, if you ask anyone
in this News Group who works for Microsoft, and I don't blame them, as
Extended MAPI is difficult enough in un-managed code.Yes, people are using
managed C++ against Extended MAPI 1.0 / CDO 1.21. But these people are
really un-managed C++ experts, they know what they are doing, or so they
should. C# works nicely with CDO 1.21, but I wouldn't even think of trying
to use C# against MAPI directly, this would be really painful.
One last thing.
Now that E12 has been announced, I can safely make the following prediction.
"I hereby predict, for the next 20 years, that the predominate API and
programming Language used for accessing Exchange Server for large amounts of
data on a LAN will be":
Un-Managed C++ and Extended MAPI 1.0.
The amazing thing about this is that Microsoft has generated over 1 Billion
dollars from Exchange Server products by the year 2004. And you can not buy
a single programming book on MAPI that is still in print (notice that I said
"IN PRINT"). You can buy a used copy of "Inside MAPI" off eBay for $340.00.
I'll bet the authors of that book are wondering why they took it out of
print. "Les Thaler", how about a Redux!
Signed,
Russell Mangel
"Scottie_do" <Scot...@discussions.microsoft.com> wrote in message
news:E0C70562-31E7-4B67...@microsoft.com...
Scottie_do
you can help me understand better.
The lowest-level access we (as general programmers) have supported access to
Exchange is MAPI, which is a COM object. Is there a name for the objects
that MAPI calls? Are they RPC's? COM objects?
And just so I understand the technologies involved....
The MIME Store you referred to is the STM files, right? And since they
share the same log files as the MAPI databases themselves, the STM databases
are internally ESE's as well - but with a different schema? Taking that a
step further, does that mean that property promotion is just a copy
(mini-export) of a message to the other database?
Lastly, does anyone know of a good newsgroup to discuss the ESE? I can't
help myself... I'm totally fascinated by it. Especially since AD, WINS, and
Exchange all use it.
-C
Russell Mangel
Billions) of dollars to create, and so you should be. Most people don't
really think about the beauty and art of creation that went into Exchange
Server. I personally have been working with it since 1996. Exchange 4.0.
Exchange 4.0 missed the Internet.
In order to really appreciate what the ESE does, you will need to start from
the beginning, and look at what happened and why. Exchange 4.0 basically
replaced the LAN based messaging system Microsoft Mail. They discovered that
in order to deliver mail across a WAN (To Branch offices), they needed some
way to solve the transfer of messages to all these remote servers planted on
remote networks. It wasn't really possible to use a LAN based transfer
technology on slow remote networks. Exchange 4.0 pulled this off with ease.
Outlook would not be released until later, and so the users where using the
"Exchange Client" to send mail. This client still works against Exchange
2000 and I believe it will connect to Exchange 2003. From time to time I
load the client and use it to test for backwards compatibility and I am
amazed and how functional the old "Exchange Client was for it's day. In fact
the only thing that makes this "Free" mail client un-useable is that it can
not render html. So when you receive an email which has html you just get
the raw html.
The JET ESE engine, and Active Directory are born, but nobody really knows
it yet.
It is important to pause here for a minute, to see how our future was
shaped. Exchange 4.0 brought us the beginnings of the ESE database, the
database was basically a modified version of Access's JET Red engine. I must
also mention that it got quite confusing to people as they thought Exchange
4.0 and later versions were just modified Access databases. This was not
true, as there were many versions of the JET database, and Exchange's
version was much different (JET Blue) and was designed for hierarchical
messaging much different than SQL . The main this to realize here is they
just used the Database Experience they had (From Jet Red (access)), to
create an Enterprise Mail Server database.
Exchange 4.0 brought us:
1. A Real Client/Server Enterprise Mail server (Not Internet, just Intranet
mail)
2. A Directory was created, which would eventually become Active Directory.
3. The first network available hierarchical database for Email, the ESE.
4. Extended MAPI 1.0 (technically the beginnings of COM)
The Exchange 4.0 development team knew by the time of the release that they
had to get Internet mail working. About 4 months later, MS came up with a
component called the Internet Mail Connector which would support Internet
mail. I personally purchased this thing for a client of ours and the time,
and I was unable to get the connector to work reliably, and I would bet that
the problem was just my own ignorance, cause I was pretty new to Enterprise
Networks. Exchange 4.0 was a short lived product, because Microsoft released
Exchange 5.0, very quickly in 1997.
Exchange 5.0, brings us LDAP protocol (this is a key technology), and a few
ESE enhancements. Internet Email was working great.
Exchange 5.5 takes the world by storm, and destroys Novell. Microsoft, now
begins to seize the entire messaging user base from Lotus Notes, and Novell
Netware's group-wise email products. One of the things that really helped
Exchange 5.0 / Exchange 5.5 was that Microsoft had a very, very, very big
client that wanted Exchange to succeed, it was DEC or Digital. Basically
Microsoft was writing Exchange Server for Digital. Outlook Web Access is
also born.
To this day Exchange Server 5.5 still has some 30% of the Exchange installed
base. One year ago it was %43, Exchange 5.5 was and still is a great mail
server. Imagine how long Exchange 2000 will live, not to mention Exchange
2003. Since the next e12 version of Exchange is also based on MAPI. I
believe that we will see 20 years of use of this technology. So it's okay,
to burn up some time learning about the history of Exchange, it's gonna be
here for a long long time.
> The lowest-level access we (as general programmers) have supported access
> to Exchange is MAPI, which is a COM object
Yes, but technically MAPI isn't 100% COM, it was where COM got started, so
it behaves a little different.
<< Is there a name for the objects that MAPI calls?
Yes, you are correct it is RPC, when you are talking to Exchange Server
database using network. And called LPC (Local Procedure Call), when you are
directly on the Exchange Server.
<< The MIME Store you referred to is the STM files, right?
Exactly, there are two databases in Exchange 2000+. There was only one
database in Exchange 4.0, 5.0, 5.5 and is called the MAPI Store, Property
Store, etc. The Mime store is native Internet Format. So this is why
Microsoft can't dump the MAPI property store, because Outlook can only talk
to the MAPI store, using RPC. The important thing to understand here is that
there are two databases. So when Outlook sends and receives messages to the
Internet, some pretty complicated things happen in the database.
<< Taking that a step further, does that mean that property promotion is
just a copy (mini-export) of a message to the other database?
I can't answer this one...
> Lastly, does anyone know of a good newsgroup to discuss the ESE? I can't
> help myself... I'm totally fascinated by it. Especially since AD, WINS,
> and Exchange all use it.
I suggest that you purchase all the Exchange Server 4.0, 5.0, 5.5, 2000, and
2003 books you can get your hands on. I have many (I scanned every page with
high speed scanner), and they do go into some very interesting things about
the database. Tony Redmond has been involved with Exchange since the
beginning, and so you will find the best ESE information in his books. I
bought many of these books from "Amazon", and from Ebay. These old books are
selling really cheap some of them are selling for $1.00 - $5.00. Get
anything from Tony Redmond. Once you have about ten of these, you will know
most everything I know.
And in closing.
If you think the ESE engine is fascinating, then just wait until you get
into: The "B-Tree data structure".
Why?
Well think about this, what is the one thing that Exchange Server, SQL
Server, and Oracle have in common?
They all use a B-Tree data structure, and this little beauty was invented in
1973 by a guy named: Robert Bayer. Without the B-Tree, Microsoft would have
no Exchange Server, or SQL Server, and Oracle would probably be some kind of
"paint" for your house instead of a database. Just imagine what the world
would be like without databases. Robert Bayer, is my personal Hero, in fact
if I was a good looking woman, I'd go to Germany and marry him so I could
learn all that he knows. But I'm a guy, so I'll just have to buy his books.
My other Hero is: Bjarne Stroustroup, the inventor of C++. Imagine, no C++.
There would be no Microsoft. You can't build huge programs with C easily.
These two guys are so smart, they could de-rail a train with a paper clip.
Russell Mangel
Las Vegas NV
"Scottie_do" <Scot...@discussions.microsoft.com> wrote in message
news:F460D541-16AE-4F51...@microsoft.com...
Kenneth Davis
I'm actually taking a longer, harder, look at Jet Blue. It will be very
important in Longhorn.
Do you have any really good references. I'm trying to determine the
behavior of Sessions and how many I might need.