I've created an ISAPI Extension in Delphi which works just fine, but I am wondering if there is a best practice on how to store configuration settings? I can think of a number of ways to do this, but I would of course like to do it the best way. I might have looked in all the wrong places, but I can't find anything that helps me out...
Is an ini or xml file in the same directory as the dll a good way? Or use the windows registry? Or is is possible (and sensible) to put ISAPI Extension-specific configuration in web.config and thereby utilize the IIS Manager to configure? Or something else?
I generally use GetModuleFileName(HInstance); to find out where the DLL is stored, and keep a file there (ini or xml). It's advisable to keep it, and the DLL, out of reach of IIS so it's not accessible over a URL.
You can use an INI file (make sure it's outside the \InetPub\ folder. Make sure you cache the INI file using TMemIniFile.
You can use a XML file. Make sure you read the XML file to cache and release the file handler after that, to prevent locked files during a concurrent read.
To check for changes while the ISAPI is loaded, check the Date/Time
stamp of the XML file before re-reading it again.
Another suggestion is to use an in-memory database and load/save the data file to and from disk.
Related
I am using Express Quantum Grid from developer express. From code i came to know that they are storing the user settings using TMemIniFile. I know the sections where they are storing but is there any way to open the Ini file and see the contents? If so where is the file located?
From code I came to know that they are storing the user settings using TMemIniFile.
The constructor of TMemIniFile receives the name of the file that stores the INI file. So, you simply need to find the call to TMemIniFile.Create and your answer will be revealed.
I want to convert my struts2 web application into an exe format so that exe file will load my project into server and database into MySQL.
Are there any such tools available for loading files into a folder?
Are there any forms other than .exe to which I could convert my project to do this action?
Is it possible to decrypt the code from class file to java file?
Which is the most secure form for a struts2 project for loading into a server?
You want to convert it to executable one?? generally installer came to assist auto installation like if you have created a product using all these technology and you want save your customer from all the setting and installation processes like database configuration,other configurations etc.
Is it possible to decrypt the code from class format to java format
there are many java d-compilers available which help you to convert .class files to java files though they sometime fails to convert it 100% but in most cases they tend to show some one what they actually want to see.
You can't load an exe file into a web server.
I suppose you could create an executable that includes a server and your war file, but I would strongly discourage the practice.
You could obfuscate (e.g., with ProGuard) and/or encrypt your .class files, but if they're determined to get to your unobfuscated byte code, they almost certainly will.
If they're not that determined, then it's probably not important enough to go through all the effort, debugging, and so on.
I'm wondering where's the best place to save some simple insensitive data? Like a few URLs and some settings.
Please advise.
If this is a per-user file, you should save it in the current user's profile. For example, on my Windows 7 system, you should use
C:\Users\Andreas Rejbrand\AppData\Local\Your Company Name\Your Product Name\Version
such as
C:\Users\Andreas Rejbrand\AppData\Local\Rejbrand\AlgoSim\2.0
To get the C:\Users\Andreas Rejbrand\AppData\Local path, you use the SHGetSpecialFolderPath function.
Settings, and specifically user-specific settings, can be stored in the registry. Have a look at the Registry unit and the TRegistry object.
Here's some demo code to get you going:
var
r:TRegistry
begin
r:=TRegistry.Create;
try
r.OpenKey('\Software\MyApplication',true);
r.WriteInteger('Setting1',Setting1);
r.WriteString('Setting2',Setting2);
finally
r.Free;
end;
end;
INI file or JSON file or XML file depending on your needs for local usage.
DB is for net usage.
It all depends on the purpose of those settings! If you want XCopy deployment, I would suggest an XML file next to the exe. But if you also need to write to this, you should find a suitable location in the current user's profile or the "all users" profile. The registry (local machine or current user) would also be a good option for simple settings.
Another question is the type of settings that you need to store. If it's simple settings, I generally start with Altova's XMLSpy to generate an XML schema, defining the structure of the settings. Then I use Delphi's XML import wizard to generate code from this schema and just use that generated code. It allows me to modify the structure in an easy way and also makes sure there's at least some documentation (the schema) telling others about the structure. It might sound complex at first, but once you're used to this, it's perfect! No more manual editing of registry settings or forgetting about the structure of your INI files. And no more thinking about writing code to read and write those settings, since Delphi will do that for you!The Registry would also be a good location for settings but not every user will have proper access rights to read from, or write to, the registry which could crash your application. Besides, the registry has some other limitations which makes it unsuitable if you need to store a lot of settings! It would be okay to store a connection string and maybe username and encrypted password for some user account, but if you need to store 40 settings or more, then the Registry becomes unsuitable.The same is true about INI files, which tend to be limited to a maximum size of 64 kilobytes. Of course, you could also store those settings in a regular text file or just some binary file. In the past, I even stored settings inside a ZIP file, because I needed to store dozens of grid-related settings. So each grid would read and write it's settings to some binary stream which would then be stored in an encrypted ZIP file.
There are many options like XML (structured data storage), ini files (simple data), databases or flat files.
I will go for XML's saved with ClientDatasets. They allow lot of options like searching, sorting, usage of the database controls and many more.
I have an ASP.NET MVC website that works in tandem with a Windows Service that processes file uploads. For easy maintenance of the site, I'd like the log file for the Windows Service to be accessible (to me, only) via the website, so that I can hit http://myserver/logs/myservice to view the contents of the log file. How can I do that?
At a guess, I could either have the service write its log file in a "Logs" folder at the top level of the site, or I could leave it where it is and set up a virtual directory to point to it. Which of these is better - or is there another, better way?
Wherever the file is stored, I can see that there's going to be another problem. I tried out the first option (Logs folder in my website), but when I try to access the file via HTTP I get an error:
The process cannot access the file 'foo' because it is being used by another process.
Now, I know from experience that my service keeps the file locked for writing while it's running, but that I can still open the file in Notepad to view the current contents. (I'm surprised that IIS insists on write access, if that's what's happening).
How can I get around that? Do I really have to write a handler to read the file and serve it to the browser myself? Or can I fix this with configuration or somesuch?
PS. I'm using IIS7 if that helps.
Unfortunately I'm afraid you'll have to write a handler that will open the file, and return it to the client.
I've written an IIS Manager extension that displays server log files, and what I've noticed that even the simple
System.IO.File.OpenRead("")
can still run in the same problem, and return the same error.. It was kind of confusing.
In the end I used
System.IO.File.Open("", FileMode.Open, FileAccess.Read, FileShare.ReadWrite)
and I could easily open the file while the server was writing logs to it :)
I think the virtual directory is an "okay" solution, if you add the directory (application) with READ ONLY rights + perhaps "BROWSE directory" too (so you can see the folder contents rendered by the IIS).
(But once you do that, you should consider that you also anonymous access to that folder - unless you enable authentication, so watch out for "secret" contents of the logfiles that you might expose? just a thought.)
Another approach, I prefer myself, is to make a MVC/ASP.NET page that does the lookup in the folder by normal code, so that you 100% can filter whatever data is shown in the HTML.
You can open the files as TextStream's and in Read Only mode.
If it's a problem to gain access to the logfolder, I would use the virtual directory with READ ONLY access and then program something that renders the logfiles as HTML on my screen and with my detail levels. Perhaps even add some sort of "login" first. But it all depends on your security levels and contents of logfiles.
is this meaningfull to you? if not, please explain more, as I've been through this thought a few times already for similar situations.
I'm having problems with deciding where to store files uploaded by user in my asp.net mvc application.
I've been using asp classic for about 10 years now, and always stored my files on disc at the site, and storing filename and folders in database.
How would you guys approach this problem?
Having them in database, and might get performance issues there? or leave it the way I always done it, and might get problems with "sync" filesystem and db?
I must have some sort of relational info in the database, so I cant store them just on disc
I'm using sql 2005 atm, and I read somewhere that sql 2008 has some sort of datacolumn now that just stores a "pointer" (like the text-datatype) to a file on disc, is that the way to go?
In some way, database is called a database for some reason, so not sure why invent wheel again? :)
Any pointers or ideas would be appreciated, I guess I'm just wondering about problems I might run into if I go with the database-approach
/M
You could use the special App_Data folder to put uploaded files and store the path into the database. If you go with SQL Server 2008 then you could take a look at the FILESTREAM type.
I'm not sure if your web application is load balanced or not, for the file management systems I've built in the past, I have always stored my files on a SAN or a network shared drive so they are accessible to all web/app servers. In addition, rather than storing the files as is, I always change the file name and type before I persist them on the file system (I typically use a GUID as the file name and a random file extension). Lastly, I would store the original file information in the database the files can be moved or copied logically rather than physically.