Ok, we are going round and round and evidently I am not capable of making myself clear.
This application is not written as a .NET assembly, it is written in a combination of VB and C++.
I could rewite the tens of thousands of lines of code in .NET, but considering the unsecure nature of .NET dlls and the relative cost of the software, I fear end users would decompile it and years of work would be lost, not to mention the issue of having to upgrade the software at the whim of Autodesk.
Now, since this is a self contained program that runs entirely on its own, it runs in its own memory space. This creates an issue with marshalling. If you understand what marshalling is, then you understand the severity of the problem, particularly considering the fact that the program grows every year to include more functionality.
Users have expressed an intrest in getting the interface to look more like their other windows. This would mean that I need to include a manifest for the program, however, given the nature of the program, the close ties it has to AutoCAD and the amount of interaction required between the two, its style should look similar to AutoCAD's. The most efficient method would be to use the AutoCAD manifest to set the style of our software. The problem is that Autodesk does not expose the manifest, however, I can still use the AutoCAD manifest by loading this software in the AutoCAD memory space. So, in the end I resolve 2 problems.
1) marshalling is eliminated
2) manifest is applied
The question is really simple, at least I think it is simple. You don't need to think about the what, where or why, only can.
That being said, can a .NET assembly written for R2004 work in all versions of R2004 - R2009 provided that the .NET assembly does not use any AutoCAD interop libraries.
This .NET assembly would merely load my software, which can be ran as a stand alone program, into the AutoCAD process. Really I don't know how much simpler I can say it, or what else I can say to make it more clear.
Now to answer a few of the questions raised
I think you started out asking about porting C++ and VB6 code to .NET...?
No I didn't, it has always been about using .NET to load another program into AutoCAD memory space
But you are also saying something about a ".NET loader" that, um... loads something into memory? ...maybe the C++/VB6 stuff?
Exactly, but the .NET assembly must be able to run on ANY version of AutoCAD from R2004 - R2009 (current versions)
I'm not really sure what you're asking, or what you are trying to accomplish. If you are simply trying to load existing C++ and VB6 stuff into memory, I'm not sure why or how you're trying to use .NET.
Why: Marshalling elimination and manifest inclusion.
How: Reference my DLL in the .NET assembly and call it from there.
If you need to provide .NET programmatic access to C++ stuff, then that would be done by creating a managed DLL for your stuff.
I don't need .NET except to load my software into AutoCAD memory space.
If you are merely trying to convert existing working code to .NET, then why are you doing that, since it sounds like you really don't want to?
No, I do not want to, .NET is notoriously insecure. It can be decompiled in merely seconds or can be edited in place without ever decompiling.
so he uses it twice and it pays for itself ?
.. thats a pretty reasonable ROI. Seems to me the client could afford to update AutoCAD by the third usage.
Without spending lots of time explaining the workflow process of the users, it would be hard to imagine. Consider this as a comparison to calculating the trajectory of a spaceship to Pluto using an abacus. Regardless, some clients have a complete ROI after 1 use, with some users it takes as many as 10 uses.
With the new release, due in the next month or so, the pricing is also increasing by about 20%-25%.
But then you can't really put a price tag on the savings you would realize if the program prevented you from making a serious mistake in your data processing. Imagine if you had a single misplaced decimal on your structural calculations for a bridge, and that bridge ultimately failed because of it ... unfathomable ... of course these things would be checked over and over again, but what if ...
Keith, Do you beta test your mission critical applications on new releases of AutoCAD before shipping? Just to make sure something is not broken?
We go through months of in house testing, trying to imagine all the ways a user would abuse the software. After we do that, we put it in a real world environment for a month or so, just to let the guys who will use it see if they can break it. Only then does it get released for general usage ... and when something is found to be broken and it is brought to our attention, we try to issue an update within 24 hours, although it has taken as long as 72 hours.
Of course we can't test for potential issues with AutoCAD 2010 ... or any other future release not yet conceived, so as such, when a company chooses to not upgrade, we want the user to be able to continue to use our software even when they do upgrade AutoCAD, without forcing an upgrade to our software. It sounds counter productive, but we have users still on the second release and we are already working on the 6th release.
To date we have had only 1 serious bug and it was resolved within hours and all users were patched. Even then, this did not affect 75% of the users. There have been maybe 4 or 5 incidental bugs since that didn't affect the end product. Not that there are not any, we just havn't found a way to break it ... yet ... but we are wtill trying.
Really , I am not trying to be difficult, I am merely wanting to speed things up for the users, and do so without burdoning the already tight production schedule.
