I tried to convert an legacy C++ program to managed C++ and build a CLR
function. However, too much compiler error. Is it possible to build a CLR
function and call/link.. the legacy C++ code?examnotes <nick@.discussions.microsoft.com> wrote in
news:DA2E1EC7-EFDB-4111-B3A9-0314A8FAA394@.microsoft.com:
> I tried to convert an legacy C++ program to managed C++ and build a
> CLR function. However, too much compiler error. Is it possible to
> build a CLR function and call/link.. the legacy C++ code?
>
As (I believe) I replied earlier to you, you need to either access the C++
object through P/Invoke or COM Interop. In your case it sounds like
P/Invoke is the most likely way of getting to the code, i.e. your C++
object is not a COM component.
Niels
****************************************
**********
* Niels Berglund
* http://staff.develop.com/nielsb
* nielsb at develop dot com
* "A First Look at SQL Server 2005 for Developers"
* http://www.awprofessional.com/title/0321180593
****************************************
**********|||Thanks. Sorry for repost.
One thing I want to know is,
It sounds CLR function required /clr:safe, can safe code still do platform
invoke?
"Niels Berglund" wrote:
> examnotes <nick@.discussions.microsoft.com> wrote in
> news:DA2E1EC7-EFDB-4111-B3A9-0314A8FAA394@.microsoft.com:
>
> As (I believe) I replied earlier to you, you need to either access the C++
> object through P/Invoke or COM Interop. In your case it sounds like
> P/Invoke is the most likely way of getting to the code, i.e. your C++
> object is not a COM component.
> Niels
>
> --
> ****************************************
**********
> * Niels Berglund
> * http://staff.develop.com/nielsb
> * nielsb at develop dot com
> * "A First Look at SQL Server 2005 for Developers"
> * http://www.awprofessional.com/title/0321180593
> ****************************************
**********
>|||examnotes <nick@.discussions.microsoft.com> wrote in
news:7205E76E-7B6D-4572-B5EF-B01A7E312456@.microsoft.com:
> It sounds CLR function required /clr:safe, can safe code still do
> platform invoke?
>
In order to do P/Invoke you need to create your assembly in SQL as unsafe.
Niels
****************************************
**********
* Niels Berglund
* http://staff.develop.com/nielsb
* nielsb at develop dot com
* "A First Look at SQL Server 2005 for Developers"
* http://www.awprofessional.com/title/0321180593
****************************************
**********|||"Niels Berglund" <nielsb@.nospam.develop.com> wrote in message
news:Xns97AADD8FEE8DEnielsbdevelopcom@.20
7.46.248.16...
> examnotes <nick@.discussions.microsoft.com> wrote in
> news:7205E76E-7B6D-4572-B5EF-B01A7E312456@.microsoft.com:
>
> In order to do P/Invoke you need to create your assembly in SQL as unsafe.
>
Running unsafe code in the database is, well, unsafe. Your legacy C++ code
can crash SQL Server. So you should check with whoever owns the production
SQL Server you will target and make sure they are OK with you running this
code inside the database.
David|||Organization: DevelopMentor
Message-ID: <Xns97AB12F509BB6nielsbdevelopcom@.207.46.248.16>
User-Agent: Xnews/2006.03.14
Newsgroups: microsoft.public.sqlserver.programming
Date: Wed, 19 Apr 2006 17:51:47 -0700
NNTP-Posting-Host: 69.177.80.118.adsl.snet.net 69.177.80.118
Path: TK2MSFTNGP01.phx.gbl!TK2MSFTNGP04.phx.gbl
Lines: 1
Xref: TK2MSFTNGP01.phx.gbl microsoft.public.sqlserver.programming:597705
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
news:ufkHThAZGHA.4836@.TK2MSFTNGP05.phx.gbl:
> Running unsafe code in the database is, well, unsafe. Your legacy C++
> code can crash SQL Server. So you should check with whoever owns the
> production SQL Server you will target and make sure they are OK with
> you running this code inside the database.
>
Well, to put things into perspective; running unsafe CLR code inside the
database is inherently safer than running extended procs. But yes, you are
right in that the code should be checked so it won't cause damage.
Niels
****************************************
**********
* Niels Berglund
* http://staff.develop.com/nielsb
* nielsb at develop dot com
* "A First Look at SQL Server 2005 for Developers"
* http://www.awprofessional.com/title/0321180593
****************************************
**********|||"Niels Berglund" <nielsb@.nospam.develop.com> wrote in message
news:Xns97AB12F509BB6nielsbdevelopcom@.20
7.46.248.16...
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> news:ufkHThAZGHA.4836@.TK2MSFTNGP05.phx.gbl:
>
> Well, to put things into perspective; running unsafe CLR code inside the
> database is inherently safer than running extended procs. But yes, you are
> right in that the code should be checked so it won't cause damage.
>
Unsafe managed code is one thing. P/Invoke to legacy C++ code is another.
David|||well, clr function call legacy dll has too much trouble,
- need to set security to let the user has permission
- or create public key and use it to sign the assembly
- parameter passing...
make the solution less favorite.
i will go to bcp to text file, processing and bulk insert back
"David Browne" wrote:
> "Niels Berglund" <nielsb@.nospam.develop.com> wrote in message
> news:Xns97AB12F509BB6nielsbdevelopcom@.20
7.46.248.16...
> Unsafe managed code is one thing. P/Invoke to legacy C++ code is another.
> David
>
>
sql
