[Openroad-users] Calling a c# DLL

Tue May 8 19:21:58 EST 2007

Hi Bodo,
  I did specify the same version (in the assembly manifest). by default
its set to [assembly: AssemblyVersion("1.0.*")], 
which causes devstudio to generate a new IID  when the interface changes
when you build so, to stop that I fixed the version number. 
That's the behaviour I'd expect since I've changed the Interface , the
new interface (with the new/changed member signatures) would require
another IID - I think VB implements this versioning system, where you
have to enable Binary Compatibility to stop the interface changing.
Fixing the Version (in .NET) prevents this as you say.

In reality, if the IID doesn't change then the version numbers are
irrelevant, I'm asking for specific interface via its IID not version
1.2.2.319 of that IID with the same CLSID, the version number forms no
part of that request. The Com guidelines specify that the interface are
immutable once published, never makes any references to the version
numbers forming part of that process. The IID is the interfaces contract
, not the version number, hence why its a royal pain in a** when you fix
the version number so your OR partner can just copy over the DLL, only
to find he has to fix the OR references _again_. You only change the IID
if you _break_ compatibility. (and even then that rarely matters unless
its a publicly available DLL or in a team where the use isn't 1:1
developer:consumer)
For example, I can still get a specific DirectX6 interface should I want
it by specifying the same IID I did 10 years ago. It doesn't matter how
many versions of DX have come and gone since then, only that specific
IID matters, so, in OR every time MS released a new version of DX, it
would lose the reference, even though nothing's changed for 10 years?
That doesn't make sense.
I have no idea what 'other' criteria OR uses as its basis for removing
the reference, but it doesn't *seem* to be just the GUID/version
numbers. OR shouldn't be maintaining its own versioning beyond the usual
IIDs anyway.
Whatever it's doing, its not going to change, I was just pointing out
that developing ActiveX to be used inside OR is a somewhat less than
optimal development experience. Since I'm (thankfully) not doing that
anymore, I'm not inclined to pursue either the reasons or the fixes :)

Cheers,
/2ob

Robert Hill 
Information Analyst (C/C++,C#,.NET,Java) 
Agile Alliance Member 
UKIMEA Technical Capabilities ADU 
UKIMEA RABU 
Application Services Field Operations EMEA 

Hallamshire Business Park, 100 Napier St, Sheffield. S11 8HD 
email:  rhill03 at eds.com 
Office: +44 114 291 1928 
Mobile: +44 7903 185 516 

This email contains information which is confidential and may be
privileged. Unless you are the intended addressee (or authorised to
receive for the addressee) you may not use, forward, copy or disclose to
anyone this email or any information contained in this email. If you
have received this email in error, please advise the sender by reply
email immediately and delete this email.

Electronic Data Systems Ltd 
Registered Office:, Lansdowne House, Berkeley Square, London  W1J 6ER 
Registered in England no: 53419 
VAT number: 432 99 5915 

________________________________

	From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Bodo
Bergmann
	Sent: 08 May 2007 09:24
	To: International OpenROAD Users
	Subject: Re: [Openroad-users] Calling a c# DLL

	Bob,

	it's not odd, what OR does in accessing COM/ActiveX libraries,
it's just strict
	(I admit , it's more strict than other development
environments).
	The versioning is part of the COM/ActiveX library, not of
OpenROAD.
	OpenROAD stores and uses the TypeLib ID (GUID) + version
information (Major + Minor) for the ExternalClassLibrary.
	So, if you change the version of the ActiveX/COM library (even
if you retain the GUID),
	then it's your part to change the information in OpenROAD
accordingly.
	It is possible (at least in MS-VisualStudio) to specify not only
to keep the same GUID, but also the same version.

	OpenROAD could be implemented less strict, e.g. it could search
for a higher version, if the specified one is not available.
	You could enter an enhancement request (in servicedesk) for
this. 

	Bodo.

	Bodo Bergmann
	Senior Software Engineer
	OpenROAD Worldwide Development
	Ingres Corp.

________________________________

	From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Hill, Robert
	Sent: Tuesday, May 08, 2007 8:57 AM
	To: International OpenROAD Users
	Subject: Re: [Openroad-users] Calling a c# DLL

	You can interface using a standard ActiveX interface.
	you could go down the C++ Mixed assembly, and this is the only
way you'll get access to OR's variables through some judicious use of
ESQL.
	It seems you can't pass OR object handles to out of process
activeX's so you're restricted to passing simple types. We found the
only way to shunt data between the two was to encode it in a string. A
team member wrote a calendar ActiveX, that was eventually withdrawn,
because it caused many problems with OR's - mouse clicks getting lost,
redraw problems etc. The control was hosted properly from other
containers, just not OR. (surprised?!)
	However I wrote a GIS Mapping application that interfaced with
our OR app through ActiveX, but that was modal, and popped up its own
WinForm - and that worked fine.
	One other thing to be aware of, is that OR seems to have
something odd going on with their versioning of ActiveX in the
catalogue. - any change to your activeX Control, and OR seems to 'lose'
the connection , even if you don't change it's guid (in C# you can
specify explicit interface guids and keep them fixed). makes for a very
frustrating development cycle, given that you can't easily automate
anything in OR.

	The benefits you do get, far outweigh the disadvantages - decent
environment, proper unit testing with mbUnit/nCoverage, proper
documentation extraction (nDoc)  , decent code analysis tools
(FXCop/Simian etc), automated builds (CC.Net/CIFactory) etc,etc.

	If you have other questions drop me a line!

	/2ob

	Robert Hill 
	Information Analyst (C/C++,C#,.NET,Java) 
	Agile Alliance Member 
	UKIMEA Technical Capabilities ADU 
	UKIMEA RABU 
	Application Services Field Operations EMEA 

	Hallamshire Business Park, 100 Napier St, Sheffield. S11 8HD 
	email:  rhill03 at eds.com 
	Office: +44 114 291 1928 
	Mobile: +44 7903 185 516 

	This email contains information which is confidential and may be
privileged. Unless you are the intended addressee (or authorised to
receive for the addressee) you may not use, forward, copy or disclose to
anyone this email or any information contained in this email. If you
have received this email in error, please advise the sender by reply
email immediately and delete this email.

	Electronic Data Systems Ltd 
	Registered Office:, Lansdowne House, Berkeley Square, London
W1J 6ER 
	Registered in England no: 53419 
	VAT number: 432 99 5915 

________________________________

		From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Paul White
		Sent: 08 May 2007 04:30
		To: International OpenROAD Users
		Subject: Re: [Openroad-users] Calling a c# DLL

		It sounds like it will be easier to do it using activeX.
I'll investigate a bit further. thanks.

________________________________

			From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Fabian
Anderson
			Sent: Tuesday, 8 May 2007 1:20 PM
			To: International OpenROAD Users
			Subject: Re: [Openroad-users] Calling a c# DLL

			Hi Paul,

			            I am not aware that OpenROAD runs on
the .NET platform as opposed to the Win32 platform.  However, if you
really must call "managed" code, you can use C++.NET to create what is
called a mixed assembly.

			            If you don't like C++ and must use
C#, then a proxy written in C++ to your C# .NET assembly will help.
C++.NET is the only .NET language capable of producing native Win32
code.

			Regards,

			Fabian Anderson

			Systems Analyst

			Fintechnix Pty Ltd

________________________________

			From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Paul White
			Sent: Tuesday, 8 May 2007 13:08
			To: International OpenROAD Users
			Subject: [Openroad-users] Calling a c# DLL

			Hello,

			Does anyone have a simple example of calling a
C#  .net function from OpenROAD?

			I've had past success with MS Visual C++.
OpenROAD needed the WINAPI DLLMain section as per the sample 3gl in
order to see the function.

			We're struggling trying to find the correct
syntax. 

			Paul

			Peerless IT Pty Ltd
			21 Evans Street,
			Braybrook VIC 3019
			Phone : 03 9214 7777
			Mobile : 0414 681 799
			Fax : 03 9318 5870
			Internet : www.peerlessit.com.au
<file:///U:\Documents%20and%20Settings\pwhite\Application%20Data\Microso
ft\Signatures\www.peerlessit.com.au> 

______________________________________________________________________
			This email has been scanned by the MessageLabs
Email Security System.
			For more information please visit
http://www.messagelabs.com/email 

______________________________________________________________________

			Specialist providers of back and front office
systems for the financial services industry.
			Featuring: Fintechnix(r)
			Disclaimer: 
			Notice: This message contains privileged and
confidential information intended only for the use of the addressee
named above. If you are not the intended recipient of this message you
are hereby notified that you must not disseminate, copy or take any
action in reliance on it.
			Any views expressed in this message are those of
the individual sender,except where the sender specifically states them
to be the views of Fintechnix Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://peerlessit.com/pipermail/openroad-users/attachments/20070508/bf52b9cd/attachment.html 