I'm currently playing around with the Microsoft.Web.Administration (MWA) namespace in order to adjust our application to configure IIS 7.5 with the new API.
I understood that all IIS level changes should be expressed in the following file (I'm on Win2K8-R2):
%WINDIR%\System32\inetsrv\config\applicationHost.config
So, when I use the ServerManager object to commit the configuration changes the file should be updated accordingly.
After adding a new MIME type (programmatic with MWA) I did not see any changes in the applicationHost.config file, but I do see the new MIME type in the IIS manager window and IIS recognizes this MIME type without problems. Even after restating the OS - The config file does not contain the newly added MIME type, but the IIS manager window does list it.
Because my application pools are forced to 32-bit (Enable32BitAppOnWin64 = true), I thought that the related config file should be located under %WINDIR%\SysWOW64\inetsrv\Config, but (if it exists...) - it also does not change after the code commits the updates.
Can someone please explain this? Am I missing something (looking at the wrong file maybe?)? Can someone please shed some light on the SysWOW64\inetsrv\config directory?
This is my code for adding the MIME type:
ServerManager manager = new ServerManager();
ConfigurationElementCollection staticContentCollection = manager
.GetApplicationHostConfiguration()
.GetSection("system.webServer/staticContent")
.GetCollection();
//MIMETypes is a string[] array, each object is {FileExt},{MIMETypeStr}
foreach (string pair in MIMETypes)
{
string[] mimeProps = pair.Split(',');
ConfigurationElement mimeTypeEl = staticContentCollection
.Where(a =>
(string)a.Attributes["fileExtension"].Value == mimeProps[0])
.FirstOrDefault();
if (mimeTypeEl != null)
{
staticContentCollection.Remove(mimeTypeEl);
}
ConfigurationElement mimeMapElement =
staticContentCollection.CreateElement("mimeMap");
mimeMapElement["fileExtension"] = mimeProps[0];
mimeMapElement["mimeType"] = mimeProps[1];
staticContentCollection.Add(mimeMapElement);
}
manager.CommitChanges();
//At this point all is working but the config file does not reflect the change
I just tried your code and it works fine. You are aware that this mime type is being added to the global mime type collection and not to a site?
It also gets added to the end of the <staticContent> list, this list isn't re-sorted when you do ServerManager.CommitChanges().
Also on Windows 2008-R2 the correct location for applicationHost.config is at:
C:\Windows\System32\inetsrv\config
I'm guess you're either using notepad.exe or NotePad2 to open this file (32 bit editors can't open it). Notepad won't reload the file upon a change and NotePad2 needs to be told to display a file change notification (alt-F5), out of the box it won't.
Also try adding something unusual like .xxx, run your update then open the config file and do a search. I guarantee it'll be there.
Update:
Further to your comments below, I'm not sure how you're able to open applicationHost.config using NotePad++ or any 32-bit editor, I certainly can't. Can you download NotePad2 which is a 64-bit editor:
http://www.flos-freeware.ch/notepad2.html
The release candidate works just fine.
On a default install of any 64 bit Windows 2008 or Windows 7 there shouldn't be an applicationHost.config in the C:\Windows\SysWOW64\inetsrv\Config folder. I'm not sure why you'd be seeing one there.
As a workaround to open and edit the 64-bit IIS configuration files with your favorite 32-bit editor that is 64-bit compatible (i.e. Notepad++), you can create a Windows directory symbolic link which points to C:\Windows\System32\inetsrv\Config. With this method, you are replacing the 32-bit Config directory, located at C:\Windows\SysWOW64\inetsrv\Config to point to the 64-bit version. If, for example, you have an application which requires both 32-bit and 64-bit versions, this method won't work.
For more information, I strongly encourage you to visit this MSDN Blog.
Related
My Android Studio application called calendar contains package spectorsky, and it works. However, when I try to save the settings by
SharedPreferences calendarSettings;
calendarSettings = getSharedPreferences("calendarINI", Context.MODE_PRIVATE);
calendarSettings.edit().putLong("TimeZone",Double.doubleToLongBits(Riseset.timezone));
and then seek saved xml via Device File Explorer, I see my package on the strange level `com.tmp.spectorsky.calendar', see printscreen:
My file system on the hard disk does not contain tmp directory anywhere concerning this application. I see that the package names on other examples contain com level (somewhat like com.package.app), but no tmp domain is observed.
So, the question: why tmp level appears in my package name, and can (and should) I get rid it?
Level com.tmp was written it two places: in the manifest file AndroidManifest.xml and in the gradle (right-click on the app in project view, Open Module Settings, ApplicationID). Then, after cleaning the project, wrong com.tmp.... directory can be deleted from the Device File Explorer.
After I uploaded my Typo3-Website onto a linux server and tryed to call the homepage, I get the error: "Could not load layout file. Tried following paths: "/Main.html", "/Main" "
I checked the correct spelling (uppercase) of my layout file: It seems to be correct and in the right place. Any ideas?
Thanks a lot. I have checked the file paths and noticed I had to delete the two slashes after the equal signs.
This works on a windows platform:
partialRootPath = /fileadmin/Private/Partials/
layoutRootPath = /fileadmin/Private/Layouts
But on a linux server it has to look this way:
partialRootPath = fileadmin/Private/Partials/
layoutRootPath = fileadmin/Private/Layouts
You seem to be using TYPO3 before 7 and the StandaloneView. In this case, identify in your code where you use this view and check the calls to setTemplatePathAndFilename or the templateRootPath. You are probably having an issue with the root path being set to something that does not exist.
This might be a situation of incompatible cAsiNg of the directory name. This is especially possible if you are testing locally on MacOS (case insensitive) and then uploading to Linux (case sensitive).
If this does not help, please provide us with more information about your scenario (code, settings, environment where it works, etc).
How can I change the .eclipse folder in Linux? I tried adding this line:
-Dosgi.configuration.area=/directory/directory1/eclipse/.eclipse
at the top of eclipse.ini but it doesn't work. I've also tried adding it to various other places in the eclipse.ini but still no luck.
Edit
I have added this line:
-Dosgi.configuration.area=file:/directory/directory1/eclipse/.eclipse
immediately below -vmargs. When Eclipse starts, it now reads from the correct .eclipse location and if .eclipse does not exist there, it creates it. Unfortunately, after Eclipse has loaded, another .eclipse folder is created in my home folder and Eclipse then continues to read from that folder. I suspect that my eclipse.ini file is now correct but there is another file I need to change.
The simplest thing to do is probably pass java a different user.home so that all the other myriad of places that derive a location base it off of user.home. So instead of what you have, use this in .ini file:
-Duser.home=/directory/other/here
In addition to .eclipse, you will probably find other directories created in your overridden user.home, such as .p2, .oracle_jre_usage, etc.
Other notes:
-Dosgi.configuration.area is the changes the configuration area for Eclipse, it does not effect user area. You also probably don't want to change that setting away from the default unless you really want multiple configurations (read more below).
Additionally, the normal thing to do would be to use -configuration as an argument to eclipse{.exe} and let eclipse convert it to the appropriate VM argument.
You probably want -user though to override the user area. Have a look at locations in the Eclipse help for more info (quoted below).
However, there are still things that have individual control over their location, such as secure storage, which is controlled by the -eclipse.keyring command line argument.
Locations
The Eclipse runtime defines a number of locations which give
plug-in developers context for reading/storing data and Eclipse users
a control over the scope of data sharing and visibility. Eclipse
defines the following notions of location:
User (-user) {osgi.user.area} [#none, #noDefault, #user.home,
#user.dir, filepath, url]
User locations are specific to, go figure,
users. Typically the user location is based on the value of the Java
user.home system property but this can be overridden. Information such
as user scoped preferences and login information may be found in the
user location.
Install (-install) {osgi.install.area} [#user.home,
#user.dir, filepath, url]
An install location is where Eclipse itself
is installed. In practice this location is the directory (typically
"eclipse") which is the parent of the eclipse.exe being run or the
plugins directory containing the org.eclipse.equinox.launcher bundle.
This location should be considered read-only to normal users as an
install may be shared by many users. It is possible to set the install
location and decouple eclipse.exe from the rest of Eclipse.
Configuration (-configuration) {osgi.configuration.area} [#none,
#noDefault, #user.home, #user.dir, filepath, url]
Configuration
locations contain files which identify and manage the (sub)set of an
install to run. As such, there may be many configurations per install.
Installs may come with a default configuration area but typical
startup scenarios involve the runtime attempting to find a more
writable configuration location.
Instance (-data) {osgi.instance.area}
[#none, #noDefault, #user.home, #user.dir, filepath, url]
Instance
locations contain user-defined data artifacts. For example, the
Resources plug-in uses the instance area as the workspace location and
thus the default home for projects. Other plugins are free to write
whatever files they like in this location.
While users can set any of
these locations, Eclipse will compute reasonable defaults if values
are not given. The most common usecase for setting location is the
instance area or, in the IDE context, the workspace. To run the
default Eclipse configuration on a specific data set you can specify:
eclipse -data c:\mydata
You must put property definitions like this at the end of the eclipse.ini after the -vmargs line. If there is no -vmargs line you must add one.
So:
.... other lines ....
-vmargs
... other arguments
-Dosgi.configuration.area=/directory/directory1/eclipse.eclipse
I wat to save a file.I use this.
FileChooser fileChooser = new FileChooser();
File file = fileChooser.showSaveDialog(null);
But in the dialog I want to suggest a name for the file, so that the user only selects a directory for the given file.The name of the file is known already.So i want to suggest that filename.
ThankYou.
This is now fixed in Javafx 2.2.45 (bundled with java 7.0_45 now) and you can do what the OP is suggesing with the following property of fileChooser, setInitialFilename, used as such:
FileChooser myFile = new FileChooser();
myFile.setInitialFileName("Whatever_file_I_want.coolFile");
Now, I don't think there is anyway to STOP the user from choosing a different file, but at leas this will give them a default you want them to pick.
Initial file name providing - it is a thing, which requires to transfer your string (initial name) through native call, to the call of the native file chooser. It is a complex thing, and you can look at these issues about its implementing :
http://javafx-jira.kenai.com/browse/RT-16111 (main one)
http://javafx-jira.kenai.com/browse/RT-24588
http://javafx-jira.kenai.com/browse/RT-24612
They all have fix version lombard, so, they are fixed in JDK 8.
So, you can specify initial file name for a file, starting from JDK 8 (you can access it, downloading JDK early access).
Recently, I've tested this feature, and it is working.
There is a method setInitialName() or smth like that.
And, as I've mentioned, it is a complex thing, and you are not likely to be able to implement it by yourself (until you are able to build jfx).
So, the decision - to wait until JDK8 release, or to use early access builds. Or, to use your own implementation of file chooser.
Here's a workaround that worked for me:
you can use javafx.stage.DirectoryChooser to select a directory for the file you want to save and after saving create a new file in this directory with the default name and extension.
DirectoryChooser dc = new DirectoryChooser();
File file = dc.showDialog(null);
if (file != null) {
file = new File(file.getAbsolutePath() + "/dafaultFilename.extension");}
I am writing a small command line utility. It should hopefully be able to run on OSX, UNIX and Linux.
It needs to save a few preferences somewhere, like in a small YAML config file.
Where would one save such a file?
Language: Python 2.7
OS: *nix
Commonly, these files go somewhere like ~/.rc (eg: ~/.hgrc). This could be the path to a file, or to a directory if you need lots of configuration settings.
For a nice description see http://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch10s03.html
I would avoid putting the file in the ~ directory only because it has gotten totally flooded with crap. The recent trend, at least on ubuntu, is to use ~/.config/<appname>/ for whatever dot files you need. I really like that convention.
If your application is named "someapp" you save the configuration in a file such as $HOME/.someapp. You can give the config file an extension if you like. If you think your app may have more than one config file you can use the directory $HOME/.someapp and create regular-named (not hidden) files in there.
Many cross-platform tools use the same path on OS X as on linux (and other POSIX/non-Windows platforms). The main advantage of using the POSIX locations isn't saving a few lines of code, but saving the need for Mac-specific instructions, and allowing Mac users to get help from the linux users in the community (without any need to translate their suggestions).
The other alternative is to put them in the "Mac-friendly" locations under ~/Library instead. The main advantage of using the Mac locations is basically "Apple says so"—unless you plan to sandbox your code, in which case the main advantage is that you can do so.
If you choose to use the Library locations, you should read About the OS X File System and OS X Library Directory Details in the File System Programming Guide, but here's the short version:
Almost everything: Create a subdirectory with your app's name or bundle ID (unless you're going out of your way to set a bundle ID, you'll get org.python.python, which you don't want…) under ~/Library/Application Support. Ideally you should use APIs like -[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] to get the path; if not, you have to deal with things like localization, sandbox containers, etc. manually.
Anything that can be easily re-created (so it doesn't need to be backed up, migrated, etc.): An identically-named subdirectory of ~/Library/Caches.
Preferences: Use the NSUserDefaults or CFPreferences APIs instead. If you use your own format, the "old" way of doing things is to create a subdirectory under ~/Library/Preferences named with your app's name or bundle ID, and put your files in that. Apple no longer recommends that, but doesn't really recommend an alternative (short of "use CFPreferences, damnit!"); many apps (e.g., Aquamacs) still do it the old way, but others instead pretend they're not preferences and store them under Application Support.
In Python, this works as follows (leaving out the error handling, and assuming you're going by name instead of setting a bundle ID for yourself):
from Foundation import *
fm = NSFileManager.defaultManager()
appsupport = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSApplicationSupportDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
caches = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSCachesDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
prefs = NSUserDefaults.persistentDomainForName_(appname)