Re: C++ for .NET development?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Ronald Laeremans [MSFT] (ronaldl_at_online.microsoft.com)
Date: 07/12/04 

Date: Mon, 12 Jul 2004 12:58:38 -0700

Basically none. All innovation from Microsoft in the API space is going to
be in managed interfaces.

Yes, ADO.Net is the preferred API over "classic" ADO (by a very large
margin). Actually it maps significantly better to what you would write if
you would have wanted to write a standard C++ API than the COM-based classic
API maps to a C++ API.

Ronald Laeremans
Visual C++ team

"MC" <MC@discussions.microsoft.com> wrote in message
news:10DEE04D-B083-4F74-9775-CF48C0680607@microsoft.com...
> Hi Daniel,
>
> No unmanaged/native functionality has been taken away, that is no
> surprise. But the question is really how much native C/C++ SDK are we
> gonna see in the future?? Already now C/C++ article on Windows all
> directed us to somewhere in .NET framework...
>
> The doubt is straight forward: Must we use ADO.NET instead of ADO for
> native development? Already several important native SDK has been stopped.
>
> "Carl Daniel [VC++ MVP]" wrote:
>
>> MC wrote:
>> > Hi Ronald,
>> >
>> > While C++ is perfectly suited to be used to write components for use
>> > in ASP.Net web pages, the question is can we continue writing such
>> > component...simply C/C++, that is, does not required .NET runtime (or
>> > simply do not /clr)??
>> >
>> > I think many us out there is interested to know how much support of
>> > pure (or UNMANAGE if you like) C/C++ is Microsoft willing to give.
>> > Microsoft cannot at one hand saying C/C++ is important, another hand
>> > stop support/development for native C/C++ SDK like SOAP, MSXML, ADO
>> > etc.
>>
>> No unmanaged/native functionality has been taken away. Indeed, VS 2005
>> has
>> significant improvements for unmanaged development.
>>
>> Of course, you can develop COM components for use on web pages, both
>> server
>> side and client side. Of course, COM components come with their own bag
>> of
>> liabilities, not the least being installation and security issues. It's
>> much easier (and generally more secure) to use a .NET component from
>> within
>> an ASP.NET server-side page, but you certainly can use a native component
>> if
>> you wish.
>>
>> -cd
>>
>>
>>

Relevant Pages

  • Re: Programming + MSDE 2000
    ... ADO is probably your best choice. ... > I want to be able to programmatically access MSDE ... > preference would be to either access MSDE databases using ... > API, if one is necessary? ...
    (microsoft.public.sqlserver.msde)
  • RE: DataSets
    ... What API are you using? ... DAO, ADO, ADO.Net? ... "Alejandra Parra" wrote: ...
    (microsoft.public.vb.database)
  • Re: Windows address book
    ... AFAIK, WAB files are not accessable by ADO. ... They have a different API: ...
    (borland.public.delphi.database.ado)
  • Most common connection method to SQL 2005
    ... I am currently using ADO from an application to connect to SQL 2005. ... or is that the most common method? ... Which API? ...
    (comp.databases.ms-sqlserver)