Develop Reference

Change string of application externally c#

I have a client application that connects to my server
I do not have access to the client's code anymore so how would I be able to change the string 192.168.2.12 into another string in order for me to be able to make it connect to my own server. In what way would I be able to do this in C# programmatically?
Thanks.

You can try to decompile the program and then search in the original source code how the value is set and adjust accordingly.

Sometimes the configuration strings are written in .exe.config
Just look at the client folder location to see if you have any files ending with .exe.config. There might be the string in it and you can change it there.

Firing an event in a tray-icon app when an exe is launched?

I'm trying to write a Tray-Icon application with WPF as a kind of add-on to a telephone software. However my only way of recieving data from said telephone software is by having it automatically execute a URI with parameters (command line or http). Essentially I can freely define the format similar to this:
trayapp.exe --num $caller.number --name $caller.name
When the telephone software recieves a call it'll automatically fill in the parameters and executes the target.
So basically I want a permanently active executable that's running in the background but my only way of getting the necessary info (like caller-number) is by passing it as a command line parameter.
Is there a good way to get the data that's being passed to a URI into my background application? It's not like I can just re-execute the tray-app, or can I? Communication via HTTP (locally!) seems overkill but I just don't know a windows-internal equivalent ...

C# ask user for servername and save for everytime application is ran

I've tried searching but had no luck as I'm not sure I'm using the correct terminology.
I'm trying to figure out how to ask a user to input their server name on the first application run, store that and insert it into filepath/connection string.
Pseudocode for initial run:
I see this is the first time you ran this application. Please input your fileserver name.
user inputs: fileserver123x
Write Fileserver123x to text file.
Initialize database connection
string fileServername = read text file;
connection = new OleDbConnection(#"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\'"+fileServerName+#"'\share\folder\Database.accdb;Persist Security Info=False;");
rest of code
I'm looking to see if there is a better/more professional way to store the user file server information other than via text file and read it each time the DB connection is initialized.
Any thoughts?

Your concept looks fine, I'd suggest a few improvements:
Store the file server name in the Windows registry instead of a text file. This is where well-behaved Windows programs store their configuration data.
Store the complete path to the database instead of the file server name. That way, your customers don't have to use a fixed share/folder name.
Make a configuration window where this configuration data can be modified. This can also serve as the window you show on your first run.
Don't read the configuration data each time a connection is opened. Read it once when your application starts and store it in a global variable.
(Note: In general, global variables are a code smell, but storing global configuration data is usually considered a legitimate use case. If you want a more advanced solution that simplifies unit testing, look into dependency injection for your configuration data.)

WP8 copy SharedStorge file directly into IsolatedStorage

I am developing a Windows Phone 8 application but am having a lot of issues with file access permission exceptions hindering the approval of my application when ever I try accessing files in the "local" folder (this only happens after the application has been signed by the WP store, not when deployed from Visual Studio). To solve this I have moved all file operations to IsolatedStorage and this seems to have fixed the problems.
I only have one problem left though. My application needs to make use of the file extension system to open external files and this seems to involve the file first being copied to the local folder where after I can then manually copy it into IsolatedStorage. I have no problem in implementing this but it seems that a file access permission exception also occurs once the system tries to copy the external file into the local folder.
The only way I think this can be solved is if I can direct the system to directly copy into IsolatedStorage but I cannot figure how to do this or if it is even possible. It seems as if though the SharedStorageAccessManager can only copy into a StorageFolder instance but I have no idea how to create one that is directed into IsolatedStorage, any ideas?
PS. Do you think that the Microsoft system might be signing my application with some incompetent certificate or something because there is not a hint of trouble when I deploy the application from Visual Studio, it only happens when Microsoft tests it or when I install it from the store using the Beta submission method.
Below is a screenshot of the catched exception being displayed in a messagebox upon trying to open a file from an email:
EDIT:
Just to make it even clearer, I do NOT need assistance in figuring out the normal practice of using a deep link uri to copy an external file into my application directory. I need help in either copying it directly into isolatedstorage or resolving the file access exception.

Listening for a file launch
When your app is launched to handle a particular file type, a deep link URI is used to take the user to your app. Within the URI, the FileTypeAssociation string designates that the source of the URI is a file association and the fileToken parameter contains the file token.
For example, the following code shows a deep link URI from a file association.
/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19
Upon launch, map the incoming deep link URI to an app page that can handle the file
// Get the file token from the URI
// (This is easiest done from a UriMapper that you implement based on UriMapperBase)
// ...
// Get the file name.
string incomingFileName = SharedStorageAccessManager.GetSharedFileName(fileID);
// You will then use the file name you got to copy it into your local folder with
// See: http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.storage.sharedaccess.sharedstorageaccessmanager.copysharedfileasync(v=vs.105).aspx
SharedStorageAccessManager.CopySharedFileAsync(...)
I've inline the information on how to do this from MSDN http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx
Read that documentation and it should be clear how to use the APIs as well as how to setup your URI mapper.
Good luck :)

Ok I figured it out. The "install" directory is actually restricted access but for some reason the Visual Studio signing process leaves the app with enough permissions to access this folder. The correct procedure of determining a relative directory is not to use "Directory.GetCurrentDirectory()" but rather to use "ApplicationData.Current.LocalFolder". Hope this helps!

DLL doesn't store string C#

I have an application that can be launched from the explorer context menu for a Windows drive. When you click the menu item the drive letter is passed to the new instance. I want to make sure that any old instance is closed.
I also want to make sure that the last drive that was selected is persisted, so that when I start the application again from the start-menu, it will remember the drive I originally selected.
It would be best if the already running application would receive an event so that it can update without having to kill and restart.
I tried the following, but that doesn't seem to be working:
This is my Class library method(it is just a line that define a variable so just i have a DLL that there a variable in it and no more)
namespace Dispatch
{
public class cls_get_drive_letter
{
public static string drive_letter;
}
}
This is my loading form code: (Here i will fill the DLL's variable)
private void Frm_loading_Load(object sender, EventArgs e)
{
Dispatch.cls_get_drive_letter.drive_letter = "XXX";
Process currentProcess = Process.GetCurrentProcess();
if (Process.GetProcessesByName(currentProcess.ProcessName, currentProcess.MachineName).Length >1)
{
currentProcess.Kill();
}
}
So when i run this for first time the "XXX" will be stored in DLL but when the current instance of application is running and i am going to run next instance of it the application will be closed because of this code:
Process currentProcess = Process.GetCurrentProcess();
if (Process.GetProcessesByName(currentProcess.ProcessName, currentProcess.MachineName).Length >1)
{
currentProcess.Kill();
}
So when closing code occurs with this code the new "XXX" will not stored in DLL and the last string will be in dll.

All variables, in this case a static field, will only remain the same for the running instance of your application.
When the application is started again the field is empty

A static variable is not stored 'inside a dll' but is stored inside the memory of the application that loads the dll. When a second instance of the application starts, it will have its own memory space and it will have its own version of the string variable. The variable is also not kept between instances, so as soon as you start a new instance it will have its own, empty string variable.
When the application is stopped, the memory for that instance is released and the variable is 'forgotten'.
If you want to share state between applications, there are all kinds of solutions, one could be the System.Configuration.Settings API, a file somewhere, a memory mapped file shared between multiple processes, a Named Pipe, a Kernel Semaphore. Options aplenty.
Until we understand exactly what it is you're trying to accomplish with this shared state, we can't provide you with a better alternative than the explanation that what you're doing right now, will not work do to the way static variables work.
Update based on new information:
You can store your currently selected drive in a Settings file for your project. You can add such file from the project properties in Visual Studio. There's a tab called settings. Create a new setting for "Selected Drive" and make it a User setting (that way you can update it without Admin rights).
To communicate a new drive letter to your already running application, you have a number of options.
For one, you could check whether your executable is already running (like you're doing now) and in that case update the settings file and exit the new instance. Your already running instance could periodically refresh the settings to pick up new values.
When your application starts, you can open a named pipe on your machine on which you listen for drive changes. When the 2nd instance starts, it can detect that the pipe is already there, write the new drive to the pipe and close. The already running application can pick up this message and change its configuration.
You can send a WindowMessage to the other application
You can host a simple WCF service to receive the notification
You can write the new drive letter to a file stored in a known location and have the other instance use a FileSystemWatcher to detect the changes to that file.
As I said the possibilities are endless.
If I were you I'd first make sure that the value is persisted between relaunches by implementing the Settings file in your application. Then investigate the options I described above, do some experimentation and then ask new questions when you cannot figure out how to make it work.