I have a class library dll that loads AutoCAD scripts from a network folder. However I need a way to ensure the class library can be updated silently. With Windows Form applications I would just use a ClickOnce Deployment and then use Application.Restart, however as this has to be a Class Library (as it is an AutoCAD addon) this doesn't seem to be possible.
What's the best way to handle this?
This is not possible with AutoCAD plugins because the DLL is loaded in the AppDomain. This 'silent' update is possible only with C++.
You can go the TDD way which is good practice. Here is a handout on the topic because TDD in AutoCAD is not that easy because of the above mentioned problem.
You can try to develop you algorithm in your own classes in order to have better TDD experience. Then transfer it with DTOs to AutoCADs transaction.
Some developers have 2 (or more) DLLs with AutoCAD code: the 1st main DLLs loads on AutoCAD startup, check for updates, download and install. The 2nd DLL actually contains the commands that will be demand loaded when the user run the command.
I recently built a solution that allows reloading the same copy of a .dll into AutoCAD.
Check out my blog with the full solution:
http://www.cadwiki.net/blogpost/How-to-reload-a-.dll-into-AutoCAD
Related
I made a simple program and now I want to make it ready for the user, I always open it in simulation but how can I turn this thing into a program for others?
You have to create a Project.
Develop your application taking care of paths, make them relative to Application directory preferably.
In Build Specificacionts you can create an Application (EXE) end installers. I recomend you that compile every mayor change and test the functionality is the same as the code.
You will need application builder license or professional LabVIEW.
There is a lot of help and info in https://forums.ni.com/
Hi guys I'm starting the design of a new little game engine and I was assuming the game engine as a DLL and then build a project for the game that would use this DLL and output an EXE file.
But then I read about the latest ID Tech Game Engines and how they do it the other way around. (http://fabiensanglard.net/doom3/index.php)
It's not really explained why though. I have the feeling it has something to do with modding as only the Game (DLL in this case) was open to the public for quite some time while the Engine (EXE) was closed source.
But I would like to know if there are other reasons for this.
As fas as I know the DLL project should have all the reusable code. The normal project should be the application, which would reference the reusable DLL. This way you can build a framework in the DLL project that can be used for any of other future projects.
The other only reason I can think of is that AFAIK only the name of the DLL is recorded in the program file, no text or data so if the Game is potentially bigger than the Engine, it could make the executable size smaller.
[EDIT]
I have thought of another reason to have it this way: The Engine is an EXE so it could be that it could be used without a Game DLL? Like for tools such as CAD or scripting?
If you are using a library in an application e.g. a game, then you have an app with an EXE with zero or more of its own DLLs consuming a library with one or more DLLs.
If you have a generic environment loading elements that customize it's behavior, thus making it a specific game, then you have an environment with an EXE and zero or more DLLs which uses configuration to load various DLLs and configuration files to determine its behaviour.
Either easy, you should probably have more than two assemblies in your application.
E.g. one (the EXE) for loading the main config and modules and connecting them all, one for the main UI, one for the graphics, one for the physics, one for the AI and etc.
Earlier I asked a question about command-line parameters to automate processing of a file in InfoPath. I'll probably get the Tumbleweed badge for that one.
Instead of attempting a batch solution through the command line, can someone suggest a good resource for developing a solution that will open an application and then perform actions through the application's user interface like opening a file, printing it, and closing the file?
I've seen a legacy application do this in the past where it would open Attachmate and perform I/O operations through Attachmate's interface - but I never saw the code.
One constraint is that the process will be initiated from an existing .NET solution (i.e. processing 10,000 files). I am also unable to rely on traditional Office macros like those found in Excel - InfoPath does not appear to support them.
One option for automating a GUI based application is to use AutoIT. It will allow you to script the actions that are necessary for clicking menu interfaces, working with dialogs, etc.
Depending on your needs, you can create an AutoIT script on your dev machine, compile it to a standard EXE, and deploy it with the .NET project's compiled artifacts. To pass data to it, either you have your AutoIT script take command line parameters, or you have the .NET solution write a to a file with all the input file parameters and have the AutoIT script read in the file to process it. Based on the number you have in the question, I'd go with the option of writing to a file.
Since you are already on .NET you might want to give the new UI Automation framework a try. I haven't tried it yet, but it is supposed to work with WPF and native Win32 applications.
MSDN also has some samples: UI Automation Control Pattern Samples
Attachmate has a scripting language, an API and all kinds of other stuff to help with automating it. So this may not have been a typical application.
On the other hand, Attachmate products are (IMO) horrible to the extreme and I will go to great lengths to avoid working with them in the first place.
I have a interesting problem: Where I work we've built a home-grown ERP system in VB6 that we are slowly moving over into vb.net. There are some projects have are in .net: we have a hand-held C# project that uses a web service to talk to our database, I've built some reporting screens using Crystal and some smaller maintenance screens.
Well as we have been plotting the conversion out, we want to have a way to separate our business logic and UI so that the UI can be a win/web form or a Smart Device project. Is this even possible? I try to reference the DLL in a test I have and it gives me this error when trying to debug using a emulator
Deployment and/or registration failed with error: 0x8973190e. Error writing file '%csidl_program_files%\smartdeviceproject1\system.windows.forms.dll'. Error 0x80070070: There is not enough space on the disk.
I'm not sure what it's doing... I take my DLL out and it works fine. Does anyone know of a way I can create a DLL that can target all of these UI without may changes?
This post here
helped me alot. Using a linked projects with conditional complation would seem to work in my case.
I have an application that uses many different .NET managed DLL's as objects (each DLL implements a common interface). Each DLL also has a version number in the file name.
Suppose I create the object "Shape~01.dll." The application will use that DLL but it can't be replaced while the application is running. So, if I want to "upgrade" the shape dll I have to create "Shape~02.dll" and the application has to dynamically search for and load the newest dll everytime a shape is created and/or the user has to restart the application. It get's worse, each dll depends on the main .exe thus has to be rebuilt with the main .exe.
Is there an easier method to have dynamically "replaceable" objects?
Well, this isn't the best solution (still thinking about it), but you can unload dll files which will allow them to be replaced. That might be a quick stopgap solution until you come up with a better idea.
You don't mention which language/platform you are trying to accomplish this in, so I will answer for the .NET Framework.
If you want to do it the hard way look at Shadow Assemblies, this is the method that ASP.NET uses to keep the site updateable though it is using the files.
For a much easier method look at the new System.Addin namespace, this uses Shadow Assemblies under the hood and should do what you want.
Instead of polling when creating an object, why not just request notification from the system when the file system changes?
The class is System.IO.FileSystemWatcher in.NET.
For native code there are a few ways to watch a folder, but IANAND (I am not a native developer ;).
Although having said those things, you probably want to rethink the reason you need to change your objects so frequently, because it will probably take a lot of work to make it work.
You used the dynamic tag, so maybe you should try a dynamic language? :)