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?
Related
I am using VS2012, Visual Basic and wish to create a Class Library.
Is it possible to restrict access to a Class Library? I am wanting to create a Class Library for the serializing of objects. This Class Library will be included in each of my applications. As such, is it possible to ensure that only my applications can use this Class Library? If so, how do I go about this?
You can make it more difficult but not entirely prevent your library being used in another application.
You can do things like obfuscate the code to make it harder to decompile, and add dummy parameters to the public methods so that it's hard to figure out how to call them.
If someone is really determined, they will find away around whatever technical measures you use. How much effort you should spend on protection, and how much effort anyone would use to get access depends on how valuable the code in the class library is.
If it is really important that no-one can use your class library, set it up as a web service, so you don't have to distribute it.
I have created a number of re-usable classes that I use across xcode projects, for example:
Utility
EmailController
MarketingController
FlashLightController
etc
I had been simply copying these class files from and back into a central repository, but now I have a number of apps it is all getting a little confusing from a config management point of view. So I was looking for an alternative.
I started investigating Static Libraries but they seem to be quite a lot of more effort for simply re-using code (e.g. different libs for device vs simulator, still having to have copies of .h files, etc).
Does anyone know of a decent alternative for quick and easy code reuse?
Thanks, Charlie
You can put the code files into a project without actually copying them into the project. In other words, just keep the class files in a completely separate location. Import them into many projects, but uncheck the option to copy them in. The projects will still refer to them successfully. Now a change made in the class files will propagate to every project that uses them.
Also, consider whether workspaces will help you.
In my view, almost anything is better than making a library or framework!
Static libraries would probably be your best bet, as I have used them and have found them to be pretty easy to use. (I haven't had to use different libraries for device or simulator, mine works on them all). Having the header isn't that annoying, and static libraries are really the only way (outside of dynamic libraries, which are banned by apple) other than copying the files to reuse code.
I intend to add a COM interface to an existing application (which, by the way, is written in C++ using Win32). I have some experience using COM objects, so I know the basic COM concepts of interfaces, etc., but this is the first time I'm actually implementing a component.
Ultimately I want to be able to use the COM interface to automate my application from scripts such as VB. I understand that there are two steps:
My application must act as an out-of-process server (i.e. I have to use MIDL and generate code for a proxy DLL and a stub DLL).
Once I have the server I can add automation capabilities by implementing the IDispatch interface.
Since the server-in-an-EXE thing with MIDL and what not is already a bit steep, I wanted to get a grasp on all that first before moving on to IDispatch.
I am reading the book "Inside COM" by Dale Rogerson and have completed the chapter on servers in EXEs (the following chapter will cover Automation).
The "Servers in EXEs" chapter provides example code that implements a server and a client. But it is necessary to start the server manually. This confuses me. Obviously, when my application (= server) is used by a client process, this extra manual step should not be necessary. Is there no mechanism to start the server automatically? Or is automation necessary to achieve that? At the moment, the prospect of having to start my server manually (once I even have one) makes me doubt I am moving in the right direction.
Hopefully someone with more knowledge of this can see what information I'm missing and point me in the right direction.
No, COM servers are not normally started by hand. Not sure why the book proposed it, possibly because it wanted to avoid talking about the registry keys you need to allow COM to automatically start the EXE. It isn't otherwise very complicated, you register the Application coclass of your app with the LocalServer32 key value giving the path to the EXE.
It is however not completely uncommon, especially with an existing program. One design decision to make is whether you let the client code completely control your program. Or if your program already has an existing user interface but you also want to expose services to other code. In the latter case it makes sense to let the user start the app by hand, like she'd normally does.
When your application is registered as LocalServer32, it will be invoked with the commandline specified there if no running process has registered a factory object for your CLSID yet.
This way, you can get the best of both worlds -- if the application is running already, this instance can provide the server side, and if it isn't, it will be started.
Automation is completely orthogonal to that -- your component becomes Automation compatible by implementing IDispatch.
Through COM, one can potentially gain absolute control over a target system. For example: using javascript's ActiveXObject object in IE, one can create certain objects which were designed to have direct access or interaction with system properties and files. One would think common sense dictates users disable ActiveX features in IE immediately after installing the browser to ensure their system is protected while surfing the net, or at least paying close attention to which websites they permit. But, I doubt many average PC users know how or why to do this, or just get tired of mirco-managing it over time. I think any PC user or admin my COM class caters to would greatly appreciate not having to deal with that. Thankfully it looks like IE versions come packaged with ActiveX disabled by default nowadays.
I've built a very versatile COM class library in VB. I didn't intend for it to be callable from any website, but that feature is just part of the COM platform. I'd like to prevent the library from being called from IE unless the website is on a white-listed domain to proactively protect the user (and ultimately their entire intranet) from harm from malicious websites. What would be the best method in VB.Net to tell which application called my DLL, to be able to tell if it was called from any command or process originating from IE? And, what domain called my dll?
Edit: I believe this might be a duplicate. See: Calling Assembly to get Application Name VB.NET
System.Environment.GetCommandLineArgs()(0) gets me the calling application path. With this info, I can compare it to a black/white-list of applications. Problem solved for now.
Don't mark the control as Safe for Scripting.
Default security settings will not allow such controls to be scripted.
Self-answer, and possibly duplicate, I suppose. See System.Environment.GetCommandLineArgs()(0) from Calling Assembly to get Application Name VB.NET
In this case, the class never was marked as safe for scripting and the intent was already never to mark it safe. The issue was how to obtain the calling application info so I could add additional security measures in case those which the calling application had were not enough.
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? :)