topic Re: .NET Subassembly Speed in .NET Forum

.NET Subassembly Speed

GTVic — Sat, 14 Nov 2015 00:51:48 GMT

My subassemblies are executing very slowly, probably a minimum of 20x slower than stock subassemblies and this seems to be simply based on where I install the VB.NET DLL.

I moved the DLL from C:\ProgramData\Autodesk\MySAFolder to C:\ProgramData\Autodesk\C3D 2015\enu and the SAs run at expected speed.

I would prefer not to install to a version specific location so any ideas on why the folder location causes this issue would be appreciated.

Thanks

Re: .NET Subassembly Speed

GTVic — Mon, 16 Nov 2015 22:48:15 GMT

No answer on the why of this problem as of yet.

Subassembly Installation:

Folder #1 - ATC, CHM and ATC support files (PNG, etc.)

Folder #2 - VB.NET DLL

Folder #1 = %ProgramData%\Autodesk\<custom folder name>\

Folder #2 = %ProgramData%\Autodesk\C3D 2016\enu\ or %AeccContent_Dir%

where %ProgramData% can be assumed to be C:\ProgramData

The advantage to this setup is a common fixed location for the ATC and HELP files and the references inside the files. The DLL being in a version specific location would be a problem except that you can specify the filename only (no path) in the ATC and palettes and Civil 3D will find it for you.

Unfortunately you can't put %ProgramData% into the ATC files or the palette but assuming almost 100% of computers use C:\ProgramData then you can get away with a fixed reference to the ATC, CHM and support files.

With this setup you can support multiple Civil 3D versions with the same 3 ATC files (catalog ATC, catalog tools ATC and palette ATC) and a fairly simple installation.

Re: .NET Subassembly Speed

fieldguy — Tue, 17 Nov 2015 00:48:20 GMT

Have you checked permissions?

Does your "Folder #1 = %ProgramData%\Autodesk\<custom folder name>\"

have the same permissions as

"Folder #2 = %ProgramData%\Autodesk\C3D 2016\enu\ or %AeccContent_Dir%"

Edit: check that - probably no relation to speed anyway

Re: .NET Subassembly Speed

GTVic — Tue, 17 Nov 2015 00:54:33 GMT

The custom folder was full read/write for all users.

I did try and add to Trusted Locations to see if that was an issue but no luck.

By default neither folder is listed in Trusted Locations and yet there is no security warning.

Re: .NET Subassembly Speed

Balaji_Ram — Tue, 17 Nov 2015 11:17:57 GMT

Hi,

I do not have much experience with Civil 3D, so my reply may not be specific to it.

But in general, AutoCAD could be searching many other folders before it finds the files in the folder where you placed it.

Please try using the ProcessMonitor to see which folders are being searched and its order.

https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

You may need to exclude many of the messages that ProcessMonitor displays that are not relevant. Right click on the unwanted messages and exclude them.

Also, have you tried adding the path to the AutoCAD support path or the system PATH variable ?

If that does not help, you may need to post your query to the Civil3D discussion forum to see if this is a known behavior.

Regards,

Balaji

Re: .NET Subassembly Speed

GTVic — Tue, 17 Nov 2015 21:39:17 GMT

Thank you for the reply, I have checked with Process Monitor.

It attempts one time to find the DLL in the following location:

<current working folder>\file:\<path\filename.atc of tool palette>\<DLL name>

This fails because of an invalid name.

All further accesses to the DLL are directly from the C:\ProgramData\Autodesk\C3D 2015\enu folder.

Also the above file access error appears to be associated with me clicking on the subassembly on the tool palette. If the subassembly is already in the drawing then modifying it or rebuilding the corridor shows all file accesses from the correct location. So I think file access or searching should not be a concern with my current solution.

Conversely, if I put the DLL in C:\ProgramData\Autodesk\MySAFolder, my original solution that was very slow, and write that path into the tool palette entry, then initially Civil 3D finds the file directly but then it goes on to search a wide number of other folders. I count 7 searches of 356 directories for a total of 2,492 searches in a span of 6 seconds for a single insertion of 1 subassembly in layout mode. A corridor rebuild using 2 subassembies on 25 stations gets 19,936 NO SUCH FILE accesses in 13 seconds. That is 356 unique directories searched 56 times for 2 subassemblies on 25 stations.

Re: .NET Subassembly Speed

augusto.goncalves — Wed, 18 Nov 2015 13:12:34 GMT

Not sure why Civil 3D is getting confused about the DLL path... maybe because you have different folders to place the files.

Anyway, you can "help Civil 3D" by hooking into the AppDomain.CurrentDomain.AssemblyResolve event and, if your DLL is the one not found, call on the correct location.

Re: .NET Subassembly Speed

GTVic — Thu, 19 Nov 2015 03:04:15 GMT

Thanks for the suggestion. The result was actually because I was trying to use a single folder. It seems like it only wants to find the DLLs in or below %AeccContent_Dir%.