I have a silverlight application which hosted in asp.net web site.
I store some information in .txt file isolated storage, in order to load it next time the application called.
Here I have a strange problem: sometimes the application doesn't find the file!
I checked what exactly happens, and discover that the isolated storage (I checked on Windows 7) composed of set of folders, their names seem as keys/guids.
when the application doesn't find the file, for some reason it goes to another key/guid folder, not to the folder the application saved the file on!
I read about it throughout the net, and understand that the key/guid folders created by microsoft according its security policy.
the code I used to create the isolated storage is:
IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForSite();
I tried also
IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication()
-the same problem.
what can I do?
I'll be glad to detail more, if necessary.
thanks a lot!
I found the problem- the website which hosts the silverlight application create two domains- one with www and another without.
this was created the two isolated storages, and cause the confusion.
I've upgraded a SharePoint WSS 3.0 farm to SharePoint 2010 Foundation.
Now I got a strange problem in a web part that modifies and creates Content Library files.
The user is only allowed to modify a file if he also got Contribute/Full access on site level (might be enough to have these permission on List/Library but I haven't tried). The user already got contribute permissions on the parent folder and on the file (inherits).
Another problem on the same site but on a different Library. All users on the site can read all files in this Library but when i try to copy a file from one list to another using the following code i get access denied when OpenBinaryStream is executed.
SPFile newFile = SPContext.Current.Web.Lists["ToLibrary"].RootFolder.Files.Add(folder + "/default.aspx", oldFile.OpenBinaryStream());
Both the problems only occurs on the upgraded farm and works fine on the WSS 3.0 farm.
Does anyone have any idea what's going on?
I had a similar issue which turned out to be a setting for lists/libraries. In the Advanced Settings for a list/library, there is a section labeled "Item-Level Permissions" - this setting can be used to deny access for anyone without Full Control rights to the item. Unless there is a specific need, Read Access should be set to Read all items and Create and Edit access should be set to Create and edit all items.
I had the same issue and resolved it by going to Site Settings > Edit Permission Level > and giving the 'Contribute' permission level the ability to 'Open Items - View the source of documents with server-side file handlers'
I am trying to write a Windows service on a PC running 64-bit Windows using Visual Studio 2008. In this service, I am trying to read a a control file from an external drive located on a different machine on the same LAN. The path to the file from the reading machine will be via a mapped network drive...( T:). I am using a TextFieldParser from Microsoft.VisualBasic.FileIO class to read the file at T:\filename. I'm getting a file not found exception, however, the path to the drive works perfectly if I copy and paste it into Windows Explorer from the same machine.
Anyone know if there are any issues connecting in this manner and/or what I am doing wrong?
Thanks for you help.
You will need to make sure that the account under which the service runs has a drive mapping to T:, or, better, try using a UNC path (e.g. \\server1\someshare\filename). And you will still need to make sure that the account has access to the file. Try to use an account with its access rights limited to only what it needs, so not the Administrator account.
Under VB.Net 2005, I created a Setup Project which produced installation files for a windows application. I placed the mdb file in the User's Application Data Folder and remapped the DataDirectory to Environment.SpecialFolder.ApplicationData at runtime. Unfortunately, sometimes the system just did create the mdb file at the Application Directory. An example was that I installed the program in Windows 7 under a normal user account. I chose inside the installer that the program would be made available to everyone. After installation, the mdb file would be created automatically for the Administrator account but not for the normal user account. For XP, the whole thing worked fine.
I am tempted to write a routine to check and create the mdb file if it is not present, but why does this happens and what other opinions do I have?
If the application is installed for all users instead of once for each user that logs onto the machine, then you will eventually run into a problem where the database isn't available for the signed on user.
In order to resolve this, you would probably be better off checking for the existence of the database on application startup and then either copying a standard version from the application directory to the current user's data directory or creating a new db from scratch in place. I would recommend the first approach.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.