Topic: Bricscad C++/C# Netload

[Pacifisto]

Okay, here's the deal.

I inherited a series of Bricscad macros that we use often for our work - things like a batch plot/convert, inserting BOMs, etc.  Up until recently, everything was in C++ using DRX.  However, the guy who used to maintain the macros had a brainwave and decided to start moving things to C#.  So he made some changes to the C++ macros and got me started on some C#, and I coded away, testing my work on my machine as I went.  All fine and good, but when I tried to push out the update to the rest of the employees, it only works for some of them.

Right now, we have a .drx file generated by the C++ project, which uses the netloader from here: http://www.theswamp.org/index.php?topic=16162.0  We can't use the built-in netloader because we're sticking with Bricscad V10 for the foreseeable future.  The netloader loads the dll created by the C# project, and everything should be hunky-dory (and it is, for a select few folks).  According to the guru, there are no prerequisites for using the C# dll, but experience has taught me otherwise.

I have included DRXNET_LIB.dll, Interop.BricscadApp.10.0.dll, Interop.BricscadApp.dll,  Interop.BricscadDb.10.0.dll, and Interop.BricscadDb.dll in the update, so the other employees' folders have the same contents as mine.  I just don't see what I'm missing - do these dlls have to be registered?  Is there some other step I'm missing?

I can provide some code snippets if necessary, but I thought I'd see if anyone knew the problem before I did.

[MCOONROD]

I just have to ask even if I can't answer your question.
What are all the other users using for OS and Acad versions? Is everything exactly the same?

[Pacifisto]

Right!  That's something I forgot to mention!

Everyone's using the same Bricscad V10 on Windows 7.  (Well, one guy's on XP, but I haven't even tried on his.)

[It's Alive!]

looks like you may be mixing up the interop DLLs, try droping the ones without the version number

[Pacifisto]

That's a good idea, and I'll get to it as soon as someone who I know has had problems is in the office at the same time I am (I only work two days a week, and there are only two people who have confirmed that the update doesn't work for them - I rolled it back before most people got it).

In the meantime though, I feel that that's not the only problem - even the two guys who have the dlls working have all the same files.

[Kerry]

</offtopic>

"__noop"

very funny Daniel

[It's Alive!]

</offtopic>

"__noop"

very funny Daniel

quite fitting, don't you think 

[Kerry]

</offtopic>

"__noop"

very funny Daniel

quite fitting, don't you think 

not for a moment

[Pacifisto]

Could 32-bit vs 64-bit Windows 7 make a difference?  I don't really have access to these computers to test things out, but I do know that not everyone has moved up to x64.

[It's Alive!]

any chance the offending dlls are on a network drive?

[Pacifisto]

Well, yes and no.  Mostly no.

The dlls are on the network drive, but when the automatic updater updates the macros to the latest version, it copies the contents of the folder on the network onto the local drive.

[It's Alive!]

I'm not exactly sure what source your using.

if your using this http://www.theswamp.org/index.php?topic=21601.0 , its long since depreciated so I can't be of much help.
but I can try to find the source code

if your using this http://www.theswamp.org/index.php?topic=29100.0  I may be able to help find the issue.

[Pacifisto]

Sorry about the slow response.  To be honest, since I inherited everything from another guy, I don't know where everything came from.  Is there a simple way to check?

I may know more in a week or two - I sent an email asking for the steps he used to prep my computer to develop the macros.  The macros didn't work on that computer before but did afterward, so some step in that process must be fixing this mystery problem.

Thanks for your help!

[Pacifisto]

Just to give this thread some closure, it seems the problem has been solved.  Unfortunately, I didn't solve it myself, so I don't know exactly what the problem was.  The DRXNET dll wasn't behaving (causing circular reference on some machines), so the guru removed all references and took a different path to the solution.  Again, I wish I could give more information, but it's kind of a black box for me.

Thanks for your help, though!