Hi all,
I have some custom tools that are developed with C#. With appropriate compiler switches and configuartion I made the code running on both: 32bit Microstation v8i SS3 and 64bit Microstation CONNECT / AECOsim.
It works perfectly on my own developer machine and on my coworkers machines (they dont have Visual Studio or stuff installed) all with WIndows 7 and all with both versions of Microstation / AECOsim.
Now we got some new PCs with Windows 10. Somehow it is not possible to load the dlls into Microstation on that Windows 10 PC. I tried both: Keyin "mdl load ..." and browsing for dll via Mdl-Dialog.As the workspace is the same, the configuartion is the same and, well, everything else is the same except Windows version I really have no idea what kind of error that could be. Microstation is not helping very much: it just gives me the usual "... could not be loaded".
Maybe someone has an idea where to search for errors? Or even HOW to search? I have no idea. I mean as it is running on the other systems it should not be useful to install Visual Studio on that Win10 machine to try to debug with Windows 10. Or maybe that would be useful indeed?
RegardsStephan
Hi Stephan,
Stephan L. said:Can I use these in Microstation configuration files?
As Jon wrote: Yes. Windows defines plenty of different (and very usefull in some cases!) variables. Some from them are defined always, some from them depends on logged user. Open Windows shell (command prompt) and type SET to list all variables.
Also be aware Bentley applications (MicroStation, bmake...) defines own set of "system pre-defined" variables, that can be used also in configuration files, scripts, make files etc.
Stephan L. said:I didn't have so much problems with individual configuration of the Visual Studio project files, so I think that is okay for me.
Usually it is "it's ok as long as it will become not" ;-) ... the only question is how painfull a future problem will be.
Stephan L. said:On the other hand if you have two different projects there would be A LOT more duplicated code I think.
Yes, the code seems to be duplicated. But for me (which is solely personal subjective opinion based on bad/good experience) they are two different products and paltformas with two different APIs, so I treat the code duplicated as just a consequence of fact APIs are similar.
For me more important is a threat APIs will behave differently or wrongly referenced assembly will usually but not always works fine and what will be a cost to test and discover such abnormal behaviour.
On the other hand, I agree this threat is small for tiny internal application(s).
Stephan L. said:Maybe I have missed something there.
I think you have not missed to much and it's understandable. These classes are used already in some exampes (e.g. DgnPrimitiveTool in PlaceGroupedHoleTools.cs) but not yet described in NET API documentation (we will see whether it will change in Update 8 SDK). Fortunately the behaviour and API is quite the same as C++ API, so MicroStationAPI can be used insted of NET doc.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point