win 7 does not allow non-admin to touch prog files folder, so not an option.
I'm actually not super inconvenienced by this issue. I can recompile all progs and throw together in one folder.
That may change fast though, so this instruction is invaluable.
Out of curiousity what did your functions Add and Substract do?
The reason I ask is I do not see how it would of worked, but that is with the assumption of trying use types defined in the autocad assemblies.
In my first post I mentioned AutoCAD does NOT allow strongly named assemblies, but should of said strongly named assemblies can only reference or use types from other strongly named assemblies.
Did the MyLib.dll have any references to autocad assemblies?
If so is 2014 autocad assemblies now strongly named?
I did not/forgot to mention that the 2 strongly signed DLLs (with the same file name and namespace in them, but different methods and different versions) that worked in the same AutoCAD process after being added into GAC) do not include AutoCAD opersions (e.g. do not have references to AutoCAD's managed API assemblies).
Yes, you are correct, since AutoCAD's .NET API assemblies cannot be strongly signed, so, if one want to strongly sign his own DLL, the DLL cannot reference AutoCAD .NET API assemblies (or any other assembly that is ot strongly sign-able). So, to your question: the 2 methods - Add() and Substract() - in the 2 same-named DLLs iin just a simple adding and substracting, no other DLLs (AutoCAD .NET assemblies) are referenced. That was meant for just making a point that side-by-side version existence requires strongly signed assenblies. I did not bother to try, but supposed that you are correct that after strongly signed, the 2 DLLs can be loaed into the same process (AutoCAD) without having to ne added into GAC.
This brings to this question to the OP: why one needs to deliberately have 2 assembly DLLs with the same file name but dufferent content in them while it almost certain that can be avoided?
Thanks for all the info was just checking I did not misunderstand something.
Enjoy reading your blog, thanks.
in reply to " question to the OP: why one needs to deliberately have 2 assembly DLLs with the same file name but dufferent content in them while it almost certain that can be avoided?"
Once I realized the acad environment only allows one of each non-strongly named dll to be loaded, I did switch to mushing together my progs in one folder, and just making sure each worked correctly.
I essentially have a set of tools that works with just autocad, then one that works on Civil3D also.
I tend to work on one or the other for weeks, but not both.
So when one gets ahead of the other, I need them separate.
I dealt with the same thing with lisp and compiling to vlx. Its always nice to the helper libraries compiled in, or at least sitting right next to a main program.
Turns out Bricscad does not yet support separate namespaces with lisp, so its the same deal where you must keep all progs up to date with helper library changes.
Having said all this, I would say the hardest part about .net is project/solution organization. It seems obvious to career programmers that work in groups, but cad managers like me that work alone, have to get advice as they run into it. No one looks over my shoulder and says "you could just do this". So threads like this are golden to me. Hopefully I will work in an experienced group someday, but my main skill is creating workflows for civil engineering and acad tasks. My company does not sell tools so its not the focus. They do appreciate the ones I do, and we are replacing Civil3D for most users with better tools than adesk writes. Its fun, but challenging to constantly improve on my .net library and processes. I'd rather be making my 3D printer
You maybe think of a solution as a tool to take projects and create assemblies from them and can have different build configurations.
For me the easiest way to create one for a class library is to use Empty Solution Template. Andchange settings like where bin folder for release is located, etc......
Would copy libriares you reference into libs folder so it easy for source control and can use from any computer and not have to worry about drive names etc...
Your Civil tools would reference the the AutoCAD Tools dll in bin folder so it will get updated version when built, but anytime AutoCAD tools is updated would need to rebuild civil tools in this type structure.
The src folder is where you put your solution.
Kinda quick and not a good explanation but will would have to explain better later.
Looking at pic below did some copying of existing folder and edited it.
DevProjs - Is top folder level
--.git - SourceControl Folder at this level
--Autodesk - Can think of this name as client
--MeadingAcadTools - Solution Folder
hmm, not sure what you mean on the acad dll's as you must set copylocal to false and always use ones in acad install folder I thought.
Right now, I have a folder for each library, and the libraries are split by function and what references are needed.
I don't use subfolders a lot in my projects.
The biggest thing was figuring out how to make things that worked for different acad and bricscad versions. I use conditional compilation symbols for that now.
I'm still wondering if its necessary to split the projects like I did.
If I use the HAH Forms CS, which has a system.windows.forms reference, in a console app, would that work or freak on that reference?
Do most places split libraries at the project level or just by code level (.cs files) and dump in one big project?
I will get a screen shot of project folder tomorrow.
You are correct and that you still set copy local to false for acad.dll's but have ever downliaded a sample and had to update path to acad's dll.?
This keeps all its 3rd party, etc.... references realative to the solution it will take up more space on your disk from multiple copies but makes it easier to use with source control and from other computers
<Reference Include="AcCoreMgd"> <HintPath>..\..\..\..\libs\Acad\v19.0\AcCoreMgd.dl
l</HintPath> <Private>False</Private> </Reference> <Reference Include="AcDbMgd"> <HintPath>..\..\..\..\libs\Acad\v19.0\AcDbMgd.dll< /HintPath> <Private>False</Private> </Reference>
not following, those paths do not point to acad install folder.
Is there a way to run things on acad dll's not in install folder?