I am attempting to create an assembly in the new C3D 2012. When I try to add any subassembly I get the following error:
"One or more subassembly.Net classes could not be found. Check the Event Viewer for more information. Continue?"
When I hit yes to continue it will let me fill out the subassembly data, then give me the same error and not add the subassembly.
The Event Viewer Descriptions:
[Subassembly.OverlayWidenMatchSlope1].Net subassembly project, module, or class not found ([\\Nas-01\cad\cad-support\acad2012\C3DStockSubass
[Subassembly.OverlayWidenMatchSlope1].Net subassembly project, module, or class not found (Source: )
This is going to the correct location on the serve (Nas-01...) and the C3DStockSubassemblies.dll file is there.
This was installed this way as part of our installation of C3D 2012.
The Subassembly dialog box list the correct location on our server also:
.Net Class Name: Subassembly.OverlayWidenMatchSlope1
.Net Assembly Name: \\Nas-01\cad\cad-support\acad2012\C3DStockSubassem
Can anyone tell me what I need to do to fix this?
I am receiving the same error and hoping to find the resolution as well. To add additional information, my error log points to the location where the 2011 information was stored, as my corridor was originally created in the previos version. Is there a way to adjust where 2012 looks for these files, or a hunt path the application takes?
SSonnen, just a quick question. Do you know if your system and network are setup to allow running DLLs over a network? That is generally considered a security risk and is not usually allowed nowadays.
Just wanted to ask if anyone has a clear solution to above ??
NONE of our Civil stock Subassemblies work when dragging from Tool Palette (R12).
We've moved rather << from 08 to R12, and have this SAME problem on all workstations 32 or 64bit.
Usually do installs / Networked (Deployments) myself, yet we paid this time, and rather lacking on getting us
back to par.
See that R12 has some pathes from client deployment that are now called "MODEL and ROOT".
Had the ROOT (that stocks the Assemblies and PipeNetwork) placed on server , and has the "C3Dstocksubassemblies.dll"
as needed. Any support path (Options) to this just still does NOT do the trick.
At current point, "could" (or is) this be a .DLL runtime issue over server ???
For our Tool Palettes, we've always had set to server (and for Authoring) so all can access other(s) work, create, etc.
Attached are current file Paths for Support and the Tool Palettes.
Our standard CAD / Tool Palettes that get set by user show up for other users, so ALL is working on the core CAD side.
Civ3D log file returns:
[Subassembly.(NAME)] .NET subassembly project, module, or class not found
(SERVER)\data\ADSK Civil\Civil3D Templates\ADSK Civ3D Root\C3DStockSubassemblies.dll ! Subassembly.(NAME)
The .DLL is at the PATH, and a Support path. Adding to the Toolpalettes path did not help.
As I look at this, SHOULD the DLL be within the "ASSEMBLIES" subdir. (Both Imperial & Metric), or ??
Sorry, just a bit lost at why failing.... and seams a logical path issue.
Request back to the firm that installed pointed us to typ. LOCAL enu dir.'s. Guess they forgot how we stepped in to
coord., and only LOCAL ref. to DLL is under the Local install dir..... \ Sample\Civil 3D API\obj\......
Greatly appreciate any thougths...
Like an earlier post said, you can't run DLL's from the server (which appears how you have it set up) unless you jump through the hoops required by Windows (http://forums.autodesk.com/t5/NET/Running-dll-from
You'll need to reinstall C3D and have these, and any other DLL's install to their default location on the local machine. If you hired someone to create deployments for you and they did this, you need to get them back to fix it...and do it for free. An expert installing C3D should know this.
BTW, the above mentioned workflow for getting DLL's to run from a network share does not work in all circumstances. Use it at your own risk.
Appreciate reply. Did see above regarding the DLL's running over Network, and having (stiill) our MIS look into config. option regarding the link ref. provided (prev. ref.ed). Yet, is it really a benefit (Should have been orig. question) ?
Given the R12 Deployments are simply creating the "ROOT" and "MODEL" dir.'s (as pathed from deployment), do
we really need to "reinstall" ? As provided in atttch., wouldn't we be able to just move these onto the local drives ?,
since the DLL ref.'s are present within the ROOT dir.
And if ADSK is letting user path this out w/o any mention of the .DLL issue, why don't they park the DLL's / support files local and simply point / embed the deployment paths for the ROOT and MODEL content that may be parked on Server ?
And.... still lost as to what should be in the MODEL dir. ??
Do have support / request regarding this issue w/ reseller that installed, yet (also still) pending reply on issue.
We asked this back in June... and gave an out-of-box reply that had nothing to do w/ our deployments.
Any insight to have "Default" dir. ref. where the ROOT and MODEL support dir.'s are for deployments? , or any ref.
regarding thier (better) management ?
Main ?, is for those "Subassemblies" that we create and share w/ users vs. the STOCK, my thought was as mentioned
w/ Tool Palettes in having them as a shared resource / users add & author and avail. to everyone (user addes to pallette,
and avail. to ALL). In prior release(s), we did have local, yet seeing this ROOT and MODEL path options within deployment I stepped in (without any discussion from reseller) and had them parked on Server based on same idea for growing our user / access to ALL Subassemblies just like our typ. blocks / commands / etc. avail. thru Tool Palettes.
Again, any ?'s on above, would REALLY appreciate.
Nothing about your problem, but...you are probably trying to save time when you type, using abbreviatoins for almost every other word. it's difficult to follow what you're saying.
About your problem, you may be able to copy them locally, but there is a registry key AECCContent_Dir that gets chnaged when you tell the deployment to move them to the server. I'm not sure it's as easy as just chaning that value and moving the files.
Also, there may be other keys that need changing, I'm not sure what/if there are.
I was able to resolve our proble by modifying the Acad.exe.Config file in the installation directory on the local machine. Here is the entirety of the file:
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> </startup> <!--All assemblies in AutoCAD are fully trusted so there's no point generating publisher evidence--> <runtime> <loadFromRemoteSources enabled="true" /> </runtime> <runtime> <generatePublisherEvidence enabled="false"/> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><probing privatePath="bin\FDO;bin;Plugins\Workflow\Activiti
Don't know if this will work for everyone, but this worked for us. Please note this fix opens a security risk many people warn about as it allows code to be loaded from remote sources. But it allows us to place company resources on a mapped drive or other network share, saving me headaches trying to manage resources.
Could someone from Autodesk give clear instructions on how to ensure the stock subassemblies are available after the primary installation. Civil 3D is design software that needs use of these subassemblies, without them you have an AutoCAD license.
Attempts to run "any" of the suggestions provided have NOT worked.
We're still sitting on 3 mo's w/o any ability to run this ROOT / MODEL support directory from the server.
If this is a .NET issue to run the .dll's off server, you would think there would be a DIRECT / SPECIFIC
solution to enable users to make this happen much more effective than having to shout on a discussion
group. Pipes / Structure library(s) work just fine, suppose to be .NET framework, yet don't see any .dll
support. So what is the hangup regarding the SubAssemblies......... ???
Not interested in becoming a .NET framework expert at this time...
A "solution" for Civil3D would be "really" appreciated.