In one webapplication i have a IHttpHandler that when invoked starts an regular application that connects to a firebird database and amongst other things parses some dates from the database.
When run from the desktop the application does what is should without any problem. But when it is started from the httpHandler is ends up with the wrong culture and fails to parse the dates.
Ive set the culture i both web.config and CurrentThread.CurrentCulture but it still ends up with the wrong one.
All of this is run from an English Windows Server 2003 with the culture set to sv-SE.
So is there a way to start an application with System.Diganotics.Process.Start with a specific culture?
If there aren't which culture does the newly started process use?
I don't think there is a way to specify the culture. The CultureInfo class is specific to .NET, and as far as I know there is no app-specific notion of a culture in windows. There is no way to specify a culture using the Process and ProcessStartInfo classes.
However, I believe the culture is associated with the current user, so what may be happening, is that your Web app is running within a different user's context, so when started from the web app, the other app gets its' users' culture settings. Therefore, you could change the culture (regional settings) for the user that is used to run the web app.
On the other hand, if its' a .NET app you're running, you could just hardcode the culture into it.
Related
I have a WPF(Windows) App for which I need to get the locale of the user or the system where application is running. I have changed the locale of my system to French as shown in the image and in the code I call "CultureInfo.CurrentCulture.Name", which is returning en-US always even though I change the locale of the system. Am I missing something here? Or is this not the right API to be used?
To solve your problem you need to use Windows Sensor API
https://code.msdn.microsoft.com/windowsapps/Windows-7-Geolocation-API-25585fac
I have a need to completely change the systems location and apply it to all accounts.
I now how to change threads but in this case I need to actually change the system location for all user accounts.
It will be a device running windows that will have a windows service that when it starts up will make a web service call back to a centrally hosted system that will tell it it's configuration including it's location. It then needs to change it's location (applying to all user accounts) and then reboot itself.
I know how to do this from the control panel but I need to pragmatically do it in C#
You can set the current user's geographical language by calling SetUserGeoID. And you can set a user's locale by calling SetLocaleInfo. However, that's just for the user account that is running the current program.
You'll need to use P/Invoke to call those methods. There might be prototypes and examples at pinvoke.net.
For copying to other users, I'm not sure. Sounds like something you'd do with WMI (Windows Management Instrumentation).
All settings are included in registry. [HKEY_USERS.DEFAULT\Control Panel\International] location. So you may change them in C# and reboot the system.
I have a service, written in C#, that monitors a set of files. It uses Growl to notify the end-user if the modified time of one of these files is over 4 hours old. I've seen situations where Growl.exe was not running under the current user's session, thus they did not receive updates. I'd like my service to check to make sure Growl is running (either Growl.exe or maybe I could look for the application ID somewhere?) and start it if it's not. How can I ensure that Growl is always running in the current user's session on any machine that this service runs on?
If the service needs to run as the current user, then why make it a service? The purpose of a service is to run at all times, even when a user is not logged in. As such, it's designed to run as a specific user at all times.
Why not convert this to a program that runs when a user logs in?
It's an interesting question, but it would appear that you can't do this as this post suggests. It seems like you can either specify that the service runs as a local system service, or as a particular user:
If your service is being started as "automatic" then you may only pre-configure a single set of credentials for the service. However, if you can identify the .exe file that the service is invoking at startup then you can create a batch file that will kick off that service at logon, at which point the active users credentials will be used by default.
Cheers,
CEC
If we give set up to the user then there is a possibility of coming changes in the code for the set up we had given to the user then we have to make set up again and then we will have to give the set up to the user, then it is not problem but user has to uninstall that set up and has to install new set up again, that is the problem then is there any other option to that ?
I am asking this question because in a application there is a chance to come changes in only one dll of the application then is there is any other option that we make the changes in that dll and give to the user and user has to update only that dll and not has to uninstall whole setup and reinstall whole setup ?
.net dlls don't need to be registered so why dont you make a small update program that would simply replace the updated dll. No need to uninstall and reinstall.
If I understand your question correctly, you are asking for a better deployment solution
for .NET based applications?
In that case I suggest you take a look at ClickOnce.
Visual Studio has ClickOnce support out of the box.
Basicaly you deploy the applications through some medium, for example via the internet,
and whenever you push a new update the customer will have the option of upgrading automatically, of you can even have your software update in the background.
If you do not want to use ClickOnce, the other option is to use MEF.
This will allow you to extend your application with so called add-ons.
These add-ons are basically classes that are loaded from assemblies at runtime.This means you could have a running application using version 1.0 of a certain assembly and even while the application is running the user could replace an assembly and the software would be up to date.
So either you use clickonce to update the entire app automatically,
or you break your application up into smaller parts, load those parts using MEF and have an installer that simply replaces parts on the target system.
When we run our application a log in window appears where a valid user have to provide his credentials to get in (Old stuff!). As they put them in and after successful sign up we fire up a web service request sending the client application meta (version, operating system, etc.). That web service is hosted on our domain. That web service struck to a default function where it query to database to get the information of the latest (or stable) release of the system and then we compare it with the information we got from a client application and send back the comparison. The receive data is a bit value which fall into a case of message window like if this is an older version client application pop up a window allow to download the newer version of the application (or the newer version is available but not compatible with your operating system etc)
We do few more stuff on successful sign up (like License Key Verification). Why after successful sign up 'cause only valid user have the right to stuck our web service
When i compile the application in my laptop it runs fine but when i run the same application in the server something is wrong with the date format. But when i checked the system date time format wit my laptop and server it the same format. Can anyone tell me what is wrong.
You also have to check the default culture set in the laptop and the server. Are they running in the same culture? Different culture settings will have different default time formats.
Is your application running on the server under a different user account? Regional settings are per-user so date and time formats will depend on the user that the application is running under. You can log in as the application user and check the Regional settings to determine if that's the issue.
This is really common in ASP.NET where the developer builds the app on their workstation and upon deployment to QA or production they find that Regional settings differ because the App Pool is using a service identity.
Is the system clock running UTC, and the OS changing it to local time on the server. This is a pretty common configuration, but will break programs that bypass the OS's functions to retrieve the date/time.