I'm using VB.net so keep that in mind.
I'm trying to create a program that is highly edible. Users will be able to change multiple things by just replacing the existing dlls. Kind of like a modding ability.
The new DLL shouldn't have to recreate every function though, it should only include the ones that it changes and then hook to the old dll for anything that it doesn't have. Is there a way to dynamically do this? Reference another dll (like a proxy) through yourself for anything that doesn't exist in its self?
Sorry if that is confusing. If it still confuses people, I'll draw a picture later =)
I'm Sorry, but it must be done this way. I have already set up everything in the manor and told clients (they have already started developing).
Sounds like you want to write a plugin architecture into your application, why re-invent the wheel, take a look at the Managed Extensibility Framework
Related
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I'll admit up front that I'm still learning good methods of deployment and that I don't have a size 12 brain to accomplish the following task. Now with that being said...
We have around 8 exe's that exist on a network drive that reference a dll that is in the same share/folder. We'd like to have a common network share in a different location that would contain this dll and any future dll's that we create so we'd have only one place to make changes (presuming the apps do not need to be recompiled). I've not found a satisfactory answer for why a dll should not be shared on a network so I'm wondering what the best practice would be for doing this. If this is something that is acceptable and routinely done then what steps are necessary to accomplish this? Thanks in advance for any help you can give.
If this shared DLL has any chance of being updated during a future release, what you have now, a local copy stored against each application, is far better.
You say your stated objective is to be able to make one change to the DLL and have all apps update. I've heard the positive side of this case made before.
"We get to roll out improvements to all our apps"
Which, seen from a half-empty glass is :-
"We get to introduce common bugs to all our apps".
Even at eight projects, imagine what your launches will be like.
"Er, hello QA. Can you test this one new app? (plus the seven others that we've done nothing to but might be broken as a result)".
Libraries should only be shared if they are mature and unlikely to change. Sorry to be so up-front about it, but I've faced a zealot who absolutely believed as you do. It was only when our bottom-line (predictably) nose-dived that my concerns were listened to. Dragons ahead. Be warned!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Objective-C Code Obfuscation
I am trying to put together an iOS package that can be reused in multiple apps. I would like to be able to bundle it up for others to easily plug in and use, and I would like to obfuscate the code so that no one can read it.
What would you recommend between building a framework, a static library, or another solution to accomplish this and why?
If you're distributing for iOS, you have two options:
Distribute a precompiled binary and headers
Distribute the source
Since you're asking about hiding stuff, I don't think #2 is what you're looking for.
As for #1, the best you can do is just not tell 3rd party users about more stuff. They'll still be able to use the runtime to find methods and properties and instance variables, etc. If you're doing everything in C-land (ie, no Objective-C classes), then they can still use things like otool to dump symbols.
In short:
It's probably not worth trying to "obfuscate" your code. Just tell them about the stuff they need to know about, then give them a .a file and the headers they need.
A framework is the standard Cocoa approach to shared code. You can distribute a framework as a compiled code library and a collection of public headers without making any of the underlying Objective-C soure code visible. Of course, a dedicated hacker could still read the machine code, but this would be a big undertaking, and probably not worth the time they would have to spend on it.
If you are really concerned about sensitive code, you could consider an internet-based service, in which your library calls out to a remote server under your control to perform some business logic. This approach is quite a bit more involved, and does not offer as much flexibility for your customers.
Does anyone know of any good free libraries providing Windows Forms controls for displaying schedules/timetables in .NET? I'm really looking for something similar to what the guy who asked this question was seeking, with a couple of differences:
I don't need any help organizing the underlying data or generating the schedule (that's all set) -- I just want a clean way of displaying it.
I'm actually looking for a custom control in Windows Forms, not an ASP.NET control.
One thing I've considered doing is just using a TableLayoutPanel control, but ideally I'm looking for something that will be more straightforward code-wise (as in, something actually designed for displaying a timetable) and sharper-looking visually.
How about this control? It is very similar to the calendar in Outlook. It does come with source code, so if it's not quite what you need you could maybe use this as a base for your own implementation.
Download the source code for http://www.monocalendar.com
He built a control (CalWidget) that you can easily recompile in your own project that's pretty nice. I recompiled it in .net 4.0 with little problems.
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? :)