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
Stephan L. said:Can I use these [Windows environment variables] in MicroStation configuration files?
Yes. If your configuration file uses a macro STEPHAN that is not defined as a MicroStation configuration variable, then it searches the operating system environment table for that symbol.
STEPHAN
Regards, Jon Summers LA Solutions
Answer Verified By: Stephan L.
Hi Jan,
thank you very, very much for the hint about correct configuration. Can I use these in Microstation configuration files? Because then I would do that of course. It is much cleaner and would have saved me a lot of time... I didn't know about that possibility.
About the second comment:
I didn't have so much problems with individual configuration of the Visual Studio project files, so I think that is okay for me.
But code polution is a point. You are right. Now there are some places inside my code where I have all that conditional copy&paste code with slight variations. On the other hand if you have two different projects there would be A LOT more duplicated code I think.
I did indeed use some parts of the new NET API because the old interop seemed to have a bug with the textstyle API for CONNECT. But yes, the new DgnTool API I didn't use. Maybe I have missed something there.
After all I have to say that my tools are pretty small, not commercial ones and I had to do the porting of the code rather quickly, so I guess it is sort of "okay" to mix those for now.
it's good to know you solved the problem and I am sure you don't have to apologize ;-)
I have two comments to the discussed issue:
In my opinion, if your environment depends on the drive change, the configuration should be done in a different way. I assume the folder D:\Users\USERNAME\ is equal to standard Windows users' profile location? In such case you should define the path using standard Windows variables that define the environment:
# DOS style path = %homedrive%\%homepath%\Addin\ # bmake / MSBuild style path = $(homedrive)\$(homepath)\Addin\
My second comment is about sharing a code between V8i and CONNECT Edition API. I remember several discussions about this topic including discussions and possible best practices evaluation during migration workshops done several years ago and the conclusion always was: "don't do it". And I agree fully with that recommendation for (at least) these reasons:
thank you for your help. Unfortunatley it was some rather stupid typo. Usually the addin dlls are stored under D:\Users\USERNAME\Addin. On Windows 10 our IT department changed that path to C:\Users\USERNAME\... I've just missed that device change. Thus the needed configuartion variables were set to the wrong path and the well known behaviour of not loading the addins happend.
I'm sorry for wasting yout time on that one...
Hi Artur,
for Addins running with CONNECT Edition I target at .NET Framework 4.6.1
But we don't use Microstation CONNECT Update 7. We use AECOsim CONNECT Update 1.The exact version number is: AECOsim Building Designer CONNECT Edition Update 1 - Version 10.01.00.36
could you please give us the exact version numbers of the MicroStation CONNECT Edition and .NET Framework installed.The use of the correct .NET Framework version is critical with building the dll for use as Addin in MicroStation.In the Visual Studio project Properties > Application > target Framework, which target version do you have set?E.g. with the recent MicroStation CONNECT Edition Update 7 the target Framework version needs to be set to 4.6.1.
ThanksArtur
There is no error number. It just says "MDL Loader: unable to load application".
I have no problems on clients running Windows 7. They can run 32bit version with "old" Microstation and 64bit version with CONNECT. On clients running Windows 10 I try to load Release builds.
I could zip an csproj file so that you could see all the settings I made. Would you like me to do that?
Ups, I haven't used the Developer shell. I just compile out of my Visual Studio. Maybe this causes problems on Windows 10 clients?
Stephan,
In addition to Jan's questions can you also provide the following?
Thank you,Bob
Sure. Inside the csproj files of Visual Studio I worked with lines like the following for the references. And when switching platforms from x86 to x64 inside Visual Studio the path to references were changed.
<Reference Include="Bentley.General.1.0"> <HintPath>..\Libs_$(Platform)\Bentley.General.1.0.dll</HintPath> <Private>False</Private> </Reference>
#if x64 using Bentley.MstnPlatformNET; #else using Bentley.MicroStation; #endif
#if x64 [AddIn(MdlTaskID = "Rahma")] #else [AddIn(KeyinTree = "Deadflower.Rahma.commands.xml", MdlTaskID = "Rahma")] #endif internal sealed class RahmaAddIn : AddIn { public static RahmaAddIn s_addin = null; private RahmaAddIn(System.IntPtr mdlDesc) : base(mdlDesc) { s_addin = this; } protected override int Run(string[] commandLine) { return 0; } }
As stated above everything works pretty fine on my Windows 7 machine. Both.