I build four different "types" of applications with my framework:
1) Windows Services
2) Normal Applications
3) Service Applications (a normal application with the functionality of a Windows Service but with a local GUI console and an ability to auto-upgrade)
4) Remote GUI Consoles
Now I can detect, through code, if the application is a Windows Service. But currently to detect between the others I use DEFINES that need to be added to the project file. I would like find an alternate way that does not rely on DEFINES if possible. My initial thoughts are to use the Comments field of the project's version info.
Any ideas?
Edit: I am after a general technique that works regardless of how I "type" my applications. At the moment I use DEFINES from the project configuration, which works, but makes the code slightly messier than using "if" code switches, and because it is stored in the .dproj file, can be hidden from view.
Solution: From David's suggestion I initially used the conditional defines (and any other information such as whether the application was running as a Windows Service) to map all applications to one of the 4 application types, stored in a globally accessible object. Unless linking files that made no sense to include with a particular application type, I replaced almost all of my conditional compilation flags with code, which significantly improved the readability of the code. There are a few other "tweaks" I implemented, but that was the basic implementation.
Depending how you are using the Application global variable you can detect if you application is a Service, a VCL or a console App checking the type of this global variable. for consoles app you can use the System.IsConsole variable.
function ApplicationIsService(Component:TComponent):Boolean;
begin
Result:=Component.ClassName='TServiceApplication';
end;
function ApplicationIsVcl(Component:TComponent):Boolean;
begin
Result:=Component.ClassName='TApplication';
end;
and you can use like this
if ApplicationIsVcl(Application) then
//do something
else
if ApplicationIsService(Application) then
//do something else
else
if IsConsole then
//do another thing
It sounds like each project has a single app type so it seems logical to differentiate in either the .dpr file or the .dproj files.
Call a function to set a private global variable from the .dpr file.
Or use a conditional defined in the .dproj as you do now.
If it was me I'd stick to a conditional but use the trick of converting it into a Delphi enum with a shared helper method to make it read better.
Related
I have an ILog interface that has multiple implementations. One will be writing to a database, one on Windows Event Log, another on an xml file, some on text files for different vendors.
Implementations of this interface are dynamically loaded using Ninject. With the growing number and the recent news on hacks and malwares sleeping on some networks, I would like to know if there is a way to filter the assemblies to only the trusted ones?
We are trying to prevent someone from just creating their own implementation of our interfaces and dropping the dll into the bin folder then they get access to the flow of our information.
Please note that we load assemblies that follows the ILog interface.
It is rather useless to try preventing this. If piece of malware can already write to the application folder, all your attempts to 'filter out' illegal dlls will always fail. The attacker can for instance simply replace the .exe and will run in the context of the user and can do everything that your application can do.
This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.
It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.
However, a couple of questions arise:
The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
(Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)
The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.
Question: Has anyone come up with a more elegant solution to this problem?
The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.
Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!
This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.
Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?
At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider
I am familiar with the solution that #Gustavo proposes, but I’ve always felt that there is something fishy about it. Something about having to specify the connection string twice… However, when I once again got the same reply, I slowly started to realize that the answer must be correct, and that it’s me who’s thinking wrong. These are my conclusions:
The reply states that you can use the GetDataContext overload that accepts a connection string. If you change this to should, things become clearer, at least to me.
The thing is that I’ve been thinking of the class definition as both a compile-time directive and as a run-time variable, but even though this is possible, it is hardly a good idea. The default value of the ConfigFile argument is as we’ve already seen “app.config”, but that file doesn’t exist (with that name) at run-time, so it doesn’t make sense to try to use it, thus leaving GetDataContext as the only reasonable option. I suggest that you do this:
Keep your compile-time settings in a file called compilation.config (or whatever you prefer) and specify this file for usage in the class definition.
Use the GetDataContext overload that accepts a connection string for run-time resolution and specify this connection string in the app.config file.
You will end up with something looking like this:
type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)
Heck, this even supports the SRP; compile-time settings in one file and run-time settings in another!
Regarding the rest of my questions, I assume that the answer lies in some scripting in the Continuous Deployment pipeline. Still interested in other solutions though.
I have Datasnap Server (DBX) that scans at startup a directory, loads the BPLs (containing the DSServerModules) and then registers them in order make them available from remote.
It all works fine for functions and procedures that use primitive types (such as integer, string and so on) but from client I cannot see any method that has "structured" variables.
For example I tried to add a function that returns a TJSONValue (as I saw on an example) but the method is not visible from client.
Strangely enough, the same function is available (and works) if the DSServerModule is added statically to the project).
Any Guess?
I didn't attach any code because it is part of a quite big project.
If need I'll provide a small example.
Cheers,
Mirko
I am using someone else's library that provides its own scripting host instance, it appears.
This lib provides me with functions to define the type of scripting language such as "jscript" and "vbscript", and I can supply it with script code and have that executed, with passing arguments in and back. So, basically, it works.
However, when I try to access the "WScript" object, I get an exception saying that this keyword is undefined.
The developer, not knowing much about this either (he only made this lib for me because I do not want to deal with Windows SDKs right now), told me that he is using "IScriptControl" for this.
Oh, and the lib also provides flags to allow "only safe subset" and "allow UI", which I set to false and true, respectively.
Does that ring a bell with anyone? Do a user of IScriptControl have to take extra steps in order to make a WScript object available? Or, can he use IScriptControl in a way that this is supplied automatically, just as when running the same script from wscript.exe?
Basically, all I need is the WScript.CreateObject function in order to access another app's API via COM.
I don't know why WScript is not known, but I suspect it is because the script host doesn't provide it. Maybe only wscript.exe does this.
If you are using Javascript, to create an object you can use new ActiveXObject(). If you are using VBScript, you can just use CreateObject.
See this article for some background.
Two Delphi programs need to load foo.dll, which contains some code that injects a client-auth certificate into a SOAP request. foo.dll resides in c:\fooapp\foo.dll and is normally loaded by c:\fooapp\foo.exe. That works fine. The other program needs the same functionality, but it resides in c:\program files\unwantedstepchild\sadapp.exe. Both aps load the DLL with this code:
FOOLib := LoadLibrary('foo.dll');
...
If FOOLib <> 0 then
begin
FOOProc := GetProcAddress(FOOLib , 'xInjectCert');
FOOProc(myHttpRequest, Data, CertName);
end;
It works great for foo.exe, as the dll is right there. sadapp.exe fails to load the library, so FOOLib is 0, and the rest never gets called. The sadapp.exe program therefore silently fails to inject the cert, and when we test against production, it the cert is missing, do the connection fails. Obviously, we should have fully-qualified the path to the DLL. Without going into a lot of details, there were aspects of the testing that masked this problem until recently, and now it's basically too late to fix in code, as that would require a full regression test, and there isn't time for that.
Since we've painted ourselves into a corner, I need to know if there are any options that I've overlooked. While we can't change the code (for this release), we CAN tweak the installer. I've found that placing c:\fooapp into the path works. As does adding a second copy of foo.dll directly into c:\program files\unwantedstepchild.
c:\fooapp\foo.exe will always be running while sadapp.exe is running, so I was hoping that Windows would find it that way, but apparently not. Is there a way to tell Windows that I really want that same DLL? Maybe a manifest or something? This is the sort of "magic bullet" that I'm looking for.
I know I can:
Modify the windows path, probably in the installer. That's ugly.
Add a second copy of the DLL, directly into the unwantedstepchild folder. Also ugly
Delay the project while we code and test a proper fix. Unacceptable.
Other?
Thanks for any guidance, especially with "Other". I understand that this issue is not necessarily specific to Delphi. Thanks!
The MSDN documentation for LoadLibrary tells you exactly where Windows will search for the DLLs. You either have to hard-code the path to the DLL, put it in the same folder as your app, or put it in one of those default search locations from the LoadLibrary docs.
This is not exactly a solution for the question asked, but it would have helped me, when I stumpled upon this question:
You can extend the search path for LoadLibrary via SetDllDirectory.
From MSDN-Doku:
The search path can be altered using the SetDllDirectory function.
This solution is recommended instead of using SetCurrentDirectory or
hard-coding the full path to the DLL.
You would have needed to add one line before your LoadLibrary call(s):
SetDllDirectory(PChar('c:\fooapp'));
Or you can simply edit the environment variable "path" and place the path to the dll in there. In this case adding ;c:\fooapp to the path should be sufficient. Since the environment changes of a parent effects a child, you can also create a loader application which adjusts the its environment variable then spawns to your application.