Prev: Configuring XML Serialization to not add an element
Next: Foreign keys using LINQ to SQL
From: Family Tree Mike on 31 Mar 2010 17:18
On 3/31/2010 5:14 PM, Family Tree Mike wrote:
> It may also be possible to keep the C++ as C++. Just build a managed c++
> dll that can be called by the web app.
>

Sorry, I meant to say keep "some of" the C++ as C++. The business logic
code was what I referred as possibly staying C++.

--
Mike
From: Mark Rae [MVP] on 31 Mar 2010 17:38
"Family Tree Mike" <FamilyTreeMike(a)ThisOldHouse.com> wrote in message
news:ec4e$eR0KHA.5344(a)TK2MSFTNGP02.phx.gbl...

>> It may also be possible to keep the C++ as C++. Just build a managed c++
>> dll that can be called by the web app.
>
> Sorry, I meant to say keep "some of" the C++ as C++. The business logic
> code was what I referred as possibly staying C++.

Well, yeah I suppose, but you'd have to convert it to managed C++ first in
order to include it as a native .NET assembly, otherwise you'd be looking at
either a COM wrapper or p/invoke.

And, at that point, you may as well convert it to C# anyway...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net

From: Peter Duniho on 31 Mar 2010 23:33
Mark Rae [MVP] wrote:
> "Family Tree Mike" <FamilyTreeMike(a)ThisOldHouse.com> wrote in message
> news:ec4e$eR0KHA.5344(a)TK2MSFTNGP02.phx.gbl...
>
>>> It may also be possible to keep the C++ as C++. Just build a managed c++
>>> dll that can be called by the web app.
>>
>> Sorry, I meant to say keep "some of" the C++ as C++. The business
>> logic code was what I referred as possibly staying C++.
>
> Well, yeah I suppose, but you'd have to convert it to managed C++ first
> in order to include it as a native .NET assembly, otherwise you'd be
> looking at either a COM wrapper or p/invoke. [...]

Unmanaged and managed C++ coexist peacefully together in the same
assembly. No conversion per se is required for plain, unmanaged C++
code. It will compile and execute unchanged in a managed assembly
(known as a mixed-mode assembly).

There is, of course, the question of how best to manage the boundary
between managed and unmanaged code. The difficulty of that will depend
a lot on the exact nature of the C++ code. If its API is based solely
on primitive types and strings, it should not be hard.

If there are a lot of complex data types that need conversion to be
included in the managed side of things, then that starts to get more
tedious. But even in that case, if there's already a large existing C++
code base, it's probably less expensive to go ahead and write the code
to glue the managed and C++ code together than to port the code.

It's hard to provide any sort of specific assessment without a specific
code example. But it's likely existing C++ code can continue to be used
without too much problem.

Pete
From: gerry on 5 Apr 2010 10:17
Once you can get the basic page setup, the auto refresh without flicker is a
relative no brainer using the built-in ASP.NET UpdatePanel and Timer
controls.
Its quick and dirty and it works. You can always tweak it later for
efficiency / bandwith etc




"r norman" <r_s_norman(a)comcast.net> wrote in message
news:p857r5ll2oc8fsreg0gq1iuh4upkebjnar(a)4ax.com...
> On Wed, 31 Mar 2010 18:24:58 +0100, "Mark Rae [MVP]"
> <mark(a)markrae.net> wrote:
>
>>"r norman" <r_s_norman(a)comcast.net> wrote in message
>>news:1tv6r5pfitv3fr6cval00oellb5to1tt94(a)4ax.com...
>>
>>> My impression from your answer is that simple ASP.NET won't do it.
>>
>>Correct.
>>
>>
>>> I would need client side scripts querying the server for new data and
>>> then updating controls on the page without a total refresh.
>>
>>Several ways. I'd (almost) certainly use the JavaScript setTimeout()
>>method
>>to make an AJAX call to a server-side method at regular intervals...
>
> Thanks again. You have pointed me in a good direction. That gives me
> some indication of how much time it will take to learn to develop a
> proper application. In the meantime, my C# .NET client using WCF
> works well so the users will just have to wait (and pay) for the
> change appropriately.
>


From: r norman on 5 Apr 2010 11:22
On Mon, 5 Apr 2010 10:17:29 -0400, "gerry" <germ2(a)newsgroup.nospam>
wrote:

>Once you can get the basic page setup, the auto refresh without flicker is a
>relative no brainer using the built-in ASP.NET UpdatePanel and Timer
>controls.
>Its quick and dirty and it works. You can always tweak it later for
>efficiency / bandwith etc
>

Thank you. I will investigate this. Other issues have now put
migration to a web-based application on the back burner.

>
>
>"r norman" <r_s_norman(a)comcast.net> wrote in message
>news:p857r5ll2oc8fsreg0gq1iuh4upkebjnar(a)4ax.com...
>> On Wed, 31 Mar 2010 18:24:58 +0100, "Mark Rae [MVP]"
>> <mark(a)markrae.net> wrote:
>>
>>>"r norman" <r_s_norman(a)comcast.net> wrote in message
>>>news:1tv6r5pfitv3fr6cval00oellb5to1tt94(a)4ax.com...
>>>
>>>> My impression from your answer is that simple ASP.NET won't do it.
>>>
>>>Correct.
>>>
>>>
>>>> I would need client side scripts querying the server for new data and
>>>> then updating controls on the page without a total refresh.
>>>
>>>Several ways. I'd (almost) certainly use the JavaScript setTimeout()
>>>method
>>>to make an AJAX call to a server-side method at regular intervals...
>>
>> Thanks again. You have pointed me in a good direction. That gives me
>> some indication of how much time it will take to learn to develop a
>> proper application. In the meantime, my C# .NET client using WCF
>> works well so the users will just have to wait (and pay) for the
>> change appropriately.
>>
>
First  |  Prev  | 
Pages: 1 2 3
Prev: Configuring XML Serialization to not add an element
Next: Foreign keys using LINQ to SQL