Comments by saurabh saini (Top 20 by date)

Thanks a lot.
I have posted this same q? on CREO plug in forms but no one able to solve it. By that I think, no one ever created .Net plug in for CREO using its C interface which more detail and have lot more functionality that its VB interface, They usually go with C or C++.
So thanks a lot.

AppenPrivatePath didn't work so I googled it & I found following blog but I didn't understand much and didn't get <probing> config file etc. Hoping you can and help me in implementing the alternative.
http://blogs.msdn.com/b/dotnet/archive/2009/05/14/why-is-appdomain-appendprivatepath-obsolete.aspx
though every thing I googled about AppenPrivatePath, people there end up telling about AssemblyResolve event. So I think it is good.

I did
String^ CorrectedPath = GetMyDllPath() + "\\" + args->Name->Split(',')[0]+".dll";
return Assembly::LoadFrom(CorrectedPath);
in CurrentDomain_AssemblyResolve
it worked.
But I have Q? what will happen if dll is not in the folder it will go in an infinite loop.
can you tell me how to avoid that.

VS giving a warning that AppendPrivatePath is Obsolete.
I tried AppDomain.CurrentDomain.SetupInformation.PrivateBinPath = GetMyDllPath()
But it didn't work.
moreover in CurrentDomain_AssemblyResolve it went in infinite loop because it was not able to load the Assembly.
what I did there is "String^ CorrectedPath = GetMyDllPath() + "\\" + args->Name;"
can you tell me how to edit that name

Yes I have removed the C++ Layer. That helped. But I am not able to add my dlls path in the search paths dynamically that's it automatically use Debug dlls from debug folder and release dlls from release folder. Right now I have to copy all dlls in exe folder. I have tried "SetDllDirectory" it doesn't work. how can I add my DLL paths in search path. From the code or as a post build command.

I tried the link you provided to influence the DLL search. But it is going bit over my head :). Can you give me a way. how can I add my DLL paths in search path. From the code or as a post build command. As during Debug mode I want some other path and while in release I want different path. I tried "SetDllDirectory" but it didn't work.

Thanks for reply.
Can you provide an example. That will be a great help.

Thanks a lot It worked. I was stuck here for more than 3 week.

Thanks for the reply.
Let's assume I have directory c:\X in which I have all my plug in dlls (C++\CLI and C# and their dependency) and I have CREO executable in C:\Y . And from command prompt I Change directory to C:\X and execute the command "C:\Y\CREO.exe" so that my working directory will be C:\X. So according to you where should I have placed my dlls, in C:\X or C:\Y ...

yes C# dll has dependencies other than those from the framework but all those dll are in the same folder as of my first C# dll (note:- other dependency dlls are all also in C#)

I didn't get what do you mean by "merge all dlls".

What is a hook assembly loading can you give me a pointer or some link to follow.

Yes I have to use that many dll though I don't want to. So I will tell you the scenario if you have any better approach you tell me. As you can see CREO is a native application and a third party software so we can't change it. Now they have given a way to write a plug in i.e. We have to have our plug in dll in native and have to export a specific function which CREO will call on runtime to execute our plug in code. And Our whole plug in was developed in C# before we have planed to integrate is with CREO so we can't change it either so we want a layer between then to communicate. We started we C++\CLI and exported that specific function from it. but CREO was not able to call it so added one more layer of pure native C++ layer in between CREO and C++\CLI. Now Calling going fine till C# i.e. CREO is able to call C++ dll and C++ dll is calling C++\CLI. So my first problem is why my exported function form C++\CLI is not getting called from CREO as I am able to call it from any other C++ Exe. One more thing CREO was compiled by Cygwin and all my dll are complied by VS2010 will it cause any problem.

Thanks for the reply.
Yes you understood the problem correctly
for the 2) consideration I built my C# layer in "Any CPU" mode is that ok.
For the 3) consideration I want to know about "in same directory of CREO"
i.e. Let's assume I have directory c:\X in which I have all my plug in dlls (C++\CLI and C# and their dependency) and I have CREO executable in C:\Y . And from command prompt I Change directory to C:\X and execute the command "C:\Y\CREO.exe" so that my working directory will be C:\X. So according to you where should I have placed my dlls, in C:\X or C:\Y ...

One more thing CREO was compiled by Cygwin and all my dll are complied by VS2010 will it cause any problem.

CREO is a very big and well know CAD software by PTC. And we are writing a plug in for that. So except CREO everything is our component and we can edit them though I want only small changes is C# component as we have used it with many other CAD software.
I have written many plug in for CREO but all those are in C++.

Thanks for your input.
Tell me if following is better.

I am writing a plug in for the host executable assemblies(exe) to be more specific for "CREO 2.0". And my project is not an executable assemblies(i.e. a EXE) it is a DLL.
So what CREO has defined, is that we give over DLL path in a TXT file which it load when executed and it tries to find function in the assembly "user_initialise" and calls it.
Now My base code is in C#. I want a way to execute my code from CERO.

My simple communication like:-
C++ -> C++\CLI -> C#. is working.

But Following is not working:-
CREO -> C++\CLI -> C#
or
CREO -> C++ -> C++\CLI -> C#

i.e. CREO is not able to Call C++\CLI but in later case CREO->C++->C++\CLI works fine but C++\CLI -> C# doesn't.

Note:- CREO also provide similar way if we have an EXE as plug in i.e. it can have EXE as plugin but I have DLL so I can leave this part.

Regards,
Saurabh

I have updated the Q?

Thanks for reply.

and Sorry If my Q? was not clear enough. Let me try again.

I really didn't wanted to give the code at first because I didn't wanted to make your reply bias to the code. My first requirement is, to know what is the best approach to tackle this problem.

I am not the owner of EXE project so I can't make any change in it. C# project is more like a plugin type of project. So I want a communication way in between them. Here the code is called by EXE not by C# i.e. EXE loads the dll from the path given in a specific txt file and then calls a specific method. And I can make a little bit change in C# project but not a big one like change the project type.

So in simple words, to start my Execution I have to create an object of a specific class from C# but as the flow given. EXE starts the calling of functionality.

If you think this is the best approach, I can provide the code, though I haven't written much of the code as I wanted to complete the calling flow.

But here, I first tried to add only C++\CLI layer in between but it didn't work, which I don't know why? as host exe calling C++ dll properly, and my C++ dll calling the C++\CLI dll properly. but when I extern the same function from C++\CLI as done from C++, host exe is not able to call it.

Moreover I am able to create a Manage object inside the C++\CLI for the class defined in the same project but when I tried same with the class defined in C# dll I am getting following exception.

I am getting following exception :-

Message = "Could not load file or assembly '<my name="" dll="">, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."

The C# dll is in the same folder.

yes I did there are too many and to complex library and most of them don't have what I want (at least in the description and it is not possible for me to try out each and every one, time constrain)that why I thought if anyone knows any library that will be great as if my concept which I am working on prove to be correct then I can write my own triangulation library...
By the way I found out this link see if you know any of them... http://www.robertschneiders.de/meshgeneration/software.html#cgal