We have a fairly robust program developed in Visual Basic .NET, and we've created an API which essentially represents the entire program as a single object. This works quite well and we've been using it for years--but now a project's come up where we really could use multiple instances of this.
The problem is that the codebase has extensive references to a global variable (gSvcMgr) in a Startup module. How can I make multiple instances of this object reference a different variable? Can I use namespaces? Or the Shadows keyword?
I can describe the structure further if I've been unclear, or if the specifics might help.
While refactoring the globals isn't out of the question if it's the only option, we have a very large code base, and only a few developers.
Thank you!
You could create each instance of your application object in a separate Application Domain using AppDomain.CreateInstanceAndUnWrap. That will create each instance of the option it a different domain where which will have its own copy of the shared global data and will not touch each other.
Using app domains will however come with a performance cost - all method calls will be marshaled (read copied) between the app domains. You will also have to derive your application object from MashalByRefObject.
See this blog post for an example of using app domains to solve a similar issue to yours.
Related
I thought these two are same thing.
Since library has also some defined building blocks and function as the API has and it also responsible for interaction also. If not then please mark difference.
A library is a collection of classes / methods you can use via referencing a compiled file. So your application is going to "include" those items and you'll need to take care of updates, deployment, etc.
An API is just an interface, so you can interact with other external applications without a direct relationship.
I have a VB.NET 2010 solution, that contains 2 projects, a class library and a Windows Forms Application.
The class library basically is a model, used for doing database integration.
I currently have the connection string placed in the class library project settings, but they do not seem to be listed anywhere in the config file of the application. What's the best practice for retrieving the connection string in the class library? I don't want to use a singleton. Should it be stored in the application or class library?
It seems the Class Library would make more sense since that is project interacting with the database. It would probably be beneficial to encrypt the connection string and store it in a file or registry key so that way if the system is compromised, the intruder will still have to crack the key to view the connection string, yet still offers you the ability to change it without recompiling your app.
I still go with what I said in your earlier question - leave the settings/configurations out of the class library. Put them in the config file for the application(s) that use the class library.
What happens if the connection string changes? Since class library's don't use config files, you'll most likely have to update the code, recompile, and redeploy it. Not a big deal if it's one program on one machine, but what if it's multiple programs and/or multiple machines?
Granted, you'd still have to make a lot of changes in a multi-program/multi-system environment via the config file, but that's a lot simpler, IMO, than recompiling (and regression testing) a class library.
Another factor to consider is what if different applications want to use this same class library? What if you have different environments that have different connection strings? And so on.
In a nutshell, I would opt to leave configuration items for the application, not the supporting class libraries. From a resusability and scalability perspective I feel that gives you the most bang for your buck.
If you only have one application and its only ever going to use this one class library, and no one else will, you can probably leave the configuration settings in it - but using the phrase "We'll never change" or "It will always be like this" is a good way to get a lot of headaches down the road.
All of the above is, of course, in my opinion, and should not be taken as me speaking officially for any other programmer or corporation :)
Edited to add
You'll have to manually move the settings you need from the class library's config to the application's config. VS won't do it for you.
And why do you keep bringing up the singleton design pattern? What potential benefit do you see from it? Or have other people been suggesting it to you?
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
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? :)
Since HTA applications are hosted within MSHTA.exe how does one provide a manifest? Plus I assume providing a MSHTA.exe.manifest could potentially break other HTA apps?
On Vista+, MSHTA.exe has an embedded manifest, which takes priority over external manifests, so your suggestion is not an option.
On XP/2003, yes, your suggestion would work, although it would be bad form, as is dropping files in System32 to modify the behavior of a system binary (especially make sure that any registration you put in the manifest are objects you are the only one to care about).
The proper solution, available on Win2003 and above, is to use the Microsoft.Windows.ActCtx object to instantiate your object given an explicit manifest reference.
For example:
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");
Perhaps, if this must work on XP as well, a path you may take is a combination of both solutions.
Edit: My answer is wrong, but I'll leave it here to avoid any similar wrong answers :)
If you question is can you access a COM object without registering it on the machine, then I think the answer is a tentative yes. However the work you would need to do would be substantial and would mean implementing a lot of the low level code that most development tools provide for you as a matter of course (Delphi, .NET, JAVA). You would need to interface with the dll directly (like you would a normal dll ), query its interfaces and call your methods.
If you have C, C++ knowledge, the way COM is accessed from these languages would give you some pointers.
Sorry I cant be of any more help.