none
Best way to launch a .net application (with parameters) from another .net app.

    Question

  • I'm trying to launch a windows installed .net application - often with parameters - for instance using file associations - from another .net application.

    The obvious way to do that is, once you have the path:

    Process.Start(path, parameters);

    Although this does launch the app, there are some problems:

    1. The lauched app. uses another 'Settings' file than when launching from the start menu. For instance if I save the form's location and size in the settings, it's easy to see the diff.

    2. When using 'Process.Start' the ApplicationDeployment.IsNetworkDeployed will always be false.

    So my question is: What is the best way to launch, in a way that works similar to launching from the start menu, only being able to provide parameters?

    BTW: I get the path from the executable itself using Application.ExecutablePath.

    I'm stuck here, any advice would be appreciated.

    Sunday, May 14, 2006 6:10 PM

Answers

  • I found the sad facts of life here:

    http://msdn2.microsoft.com/en-us/library/ms172242.aspx

    "It is not possible to pass command-line arguments to a ClickOnce application. If you want to supply arguments to the application, you must deploy it over the Web and supply query string parameters in the URL."

    Well, I get more and more convinced, that all the limitations of .net will make it a fun experiment, and nothing more. You can't develop real windows applications and noone use web-applications, so it will silently die (the only .net applications on my comp. are my own). That's probably the reason why MS has given the Express products away for free (so unlike MS!).

    Tuesday, May 16, 2006 9:04 PM

All replies

  • If the application "uses another Settings file" - I hope/would like to add that the settings file is being loaded from within the application itself, I am sure this is the case.

    Your application should have a location where all the application settings are stored - so in the application it would load those files from the path set as the output directory.

    I dont quite understand your question but would appreciate if you could expand a bit more on what you would like to achieve at the end of the day! :)

    • Proposed as answer by Najeeb Kechery Wednesday, February 18, 2009 9:44 AM
    Monday, May 15, 2006 12:09 AM
    Moderator
  •  ahmedilyas wrote:

    If the application "uses another Settings file" - I hope/would like to add that the settings file is being loaded from within the application itself, I am sure this is the case.

    That is true, but it uses a different path to the settings file when launched with Process.start (or start menu 'Run') than when using the shortcut in the start menu. I can find both settings files, but no logic in the paths to these files.

     ahmedilyas wrote:

    Your application should have a location where all the application settings are stored - so in the application it would load those files from the path set as the output directory.

    Agree, that's what I thought, too.

    What do you mean, when you say 'from the path set as the output directory' ?

    Do you mean the path where the installed app is? If so, it's not true. That's only the default settings file, not the ones you have changed.

     ahmedilyas wrote:

    I dont quite understand your question but would appreciate if you could expand a bit more on what you would like to achieve at the end of the day! :)

    Well, I simply want to launch a .net application programmatically in such a way that it works like when I launch it from the start menu shortcut, ought to be simple

    BTW: I use : Properties.Settings.Default to read/write the settings from code.

    Will it help to set the 'Working directory' in ProcessStartInfo (shouldn't be nessecary in a Windows app) ?

    Monday, May 15, 2006 3:24 AM
  • what I mean by the output directory is just some set directory where all the application files are stored, wether it being in the program files or some user set directory (my docs?)

    What's so different from launching it from the start menu? The start menu has a shortcut to the exe application (with switches?) - just simply copy the shortcut value - application name and any switches after it :)

     

    Right click the shortcut on the start menu of your application and choose properties, then copy and paste here the "Target" and Value/run variables :)

     

    Other thing you could do I guess is to get the start menu path to the shortcut and execute that.

    Monday, May 15, 2006 10:08 AM
    Moderator
  • Your solutions don't work:

    1. a start menu shortcut is not a standard windows shortcut, but an 'application reference'. Just try to look at the properties. No target/parameters, you can get - the actual path is hidden. No way to provide parameters.

    From the registry, I can see the  following command for 'Application reference":
    rundll32.exe dfshim.dll,ShOpenVerbShortcut %1

    That's what is executed, when you choose from the start menu. As you can see, no parameters (%1 is the .net exe).

    But I need to pass parameters, so I can't use the start menu.

    2. As mentioned, when I launch the .net application directly, it uses a different settings file (and other things are also different).
    Just try to copy a .net path to the start menu's run window and you can see for yourself.
    The app. will run, but with different settings.

    Surely there must be a way, why else do we have GetCommandLineArgs ?

    Monday, May 15, 2006 7:17 PM
  • Can you be more specific of which "settings" your app is loading?  Is it using ConfigurationManager (.NET20) or the Configuration Block in EntLib (.NET1.X) or are you manually opening/reading it yourself based on some path (i.e. Application.StartupPath).

    Right now, it's a bit unclear on what would cause it to be different, or what IS different.  You also mentioned using the WorkingDirectory...I take it that you're not using ProcessStartInfo?  I always use ProcessStartInfo when launching applications.

    your psi should look something like:
    psi.WorkingDirectory = @"C:\myDir"
    psi.FileName = "mydotnetapp.exe"
    psi.Arguments = "/a /b" or whatever command line args you want
    Then call Process.Start(ProcessStartInfo startInfo) instead of Process.Start(string filename, string arguments)

    Doing it that way has never given any problems with the directories, and inevitably any files it tries to access.

    Although, judging from the amount of time this issue may have already caused you, I will guess that you've already used the ProcessStartInfo object, and still have the same unwanted behavior.

    Also, you said that it's using different settings.  So when you're storing your window's last location, are you checking whether the setting exists first? If not, it should blow up when it attempts to access the setting when it loads the "incorrect" setting, correct?  Or if you have a failsafe logic in there, then you potentially have two files on your hd that have the windows location setting...in which case, maybe the location of the 2nd file will tell you a bit more of where it's getting the 2nd setting from.

     

    Monday, May 15, 2006 11:13 PM
  • I found the sad facts of life here:

    http://msdn2.microsoft.com/en-us/library/ms172242.aspx

    "It is not possible to pass command-line arguments to a ClickOnce application. If you want to supply arguments to the application, you must deploy it over the Web and supply query string parameters in the URL."

    Well, I get more and more convinced, that all the limitations of .net will make it a fun experiment, and nothing more. You can't develop real windows applications and noone use web-applications, so it will silently die (the only .net applications on my comp. are my own). That's probably the reason why MS has given the Express products away for free (so unlike MS!).

    Tuesday, May 16, 2006 9:04 PM
  • It might have been helpful to have mentioned that this was a click-once application.  By the way, click-once is not all of .NET.  Looking at the bottom line of your last post, I guess this doesn't matter anyway.
    Tuesday, May 16, 2006 11:29 PM
  • So because you can't directly pass arguments to a ClickOnce application, you reason that you can't develop "real windows applications".  Please provide something reasonable here...how you deploy an application is different from how you develop it.  Sure there may be some constraints in designs in some cases...but if you HAVE to deploy via ClickOnce, attack the problem...I'm sure you can come up with something.  Well...maybe.

    I get this nasty feeling you're just trolling this site.

    Thursday, May 18, 2006 7:01 PM
  • Jayson, please don't attack me, just because you don't understand the problem!

    First, I admit that my last post was written in frustration. Finding such a major restriction did make me frustrated, and the post reflects this. However, I will leave it, as it is, because I don't think my arguments are wrong.

    I had a problem, I asked, if anyone knew a solution. What have I done wrong?

    To LMcFarlin: You are obviously right, I should have mentioned more clearly, that I'm using ClickOnce.

    However:

    1. When I asked, I did not know, that the problem was related to ClickOnce (I know that now).

    2. Using an Express product, .NET and ClickOnce is "the same". At least, I did not distinguish.

    3. In my post, I mention: 'ApplicationDeployment.IsNetworkDeployed'. I also say that the shortcut is an ''Application reference'. Both are ClickOnce-only 'things' and should lead you on the track, right?

    Now, knowing the problem and my workaround, I will describe it here, if anyone else read this thread, having the same problem:

    ClickOnce creates a shortcut in the start menu. However, this is not a standard Windows shortcut (.lnk) but an 'Application reference' (.appref-ms). An 'Application reference' target is launched via 'rundll32.exe dfshim.dll,ShOpenVerbShortcut %1' which is causing all the problems:

    1. It won't allow to pass parameters to the appliction.

    2. Application settings (accessed via 'Properties.Settings.Default') are saved in a different location (still a mystery to me why and how) than if you launch your application the standard way (like 'Process.Start', via a registry command or via the start menu's 'Run' command).

    My work around is actually quite simple: I delete the ClickOnce-created shortcut from the start menu and create a standard Windows shorcut, pointing to my executable. Now it always uses the same settings file location and I can pass parameters and launch my app. anyway I want.

    The 'catch' is of course: My own shortcut will not be deleted when the app. is uninstalled. Neither will any file associations I have made nor any other registry settings. This is why I call it a workaround, good enough for me, but not for a professional application. Doing an update will also change the path to the executable, making the new shortcut useless.

    Now that you know what the real problem is, I think, you better understand my frustrations and why I state that you can't develop 'real Windows applications' using ClickOnce (I now know this is not directly caused by .net).

    However, if you still don't like my last post, please comment on this: "the only .net applications on my comp. are my own". I mean, .net is old now, so what does that tell you?

    Saturday, May 20, 2006 4:01 PM
  • I know this is an old thread.. however I am having the exact same problem and came here looking for a solution!  It seems over a year later there still isn't one?

     

    I also have been forced to revert to a manual shortcut to the actual EXE file in order to pass command line parameters, and yes each time the application is updated and reinstalled (which is frequently for me as I'm still developing it) I have to go and search out the executable and manually update my shortcut - NOT ideal!

     

     

     

     

    Tuesday, July 03, 2007 10:22 PM
  • I'm late to the game here but I knew you were talking about ClickOnce when I read your post when you mentioned IsNetworkDeployed.

     

    You can pass parameters to a ClickOnce application via a URL.  We do this all the time when launching ClickOnce apps.  Just use the Process.Start() as you had but instead of passing in the .exe just pass in the URL of the application along with any parameters you need and it'll work.

     

    Cheers.

     

    -keith

    Wednesday, July 18, 2007 7:04 PM
  • Ok, this might sound promising, but I don't think I quite understand.

    When you say 'pass the url', do you mean the url of the 'application reference' (from the start menu) or the url of the exe file itself?

    And in what format do you pass parameter?

    A short example would be great

    Thursday, July 19, 2007 10:43 PM
  • Setup:
    Right click the ClickOnce project -> properties -> publish tab -> options.
    Select "Allow URL Parameters to be passed to application"

    Starting the ClickOnce project through code:
    Process.Start("http://localhost/TestingProject/TestingProject.application?x=somevalue")

    Retrieving all parameters:
    Private Function getQueryStringParameters() As NameValueCollection
        If (ApplicationDeployment.IsNetworkDeployed) Then
            Return HttpUtility.ParseQueryString(ApplicationDeployment.CurrentDeployment.ActivationUri.Query)
        End If
        Return New NameValueCollection()
    End Sub

    Retrieving the value of x:
    Dim newX As String = getQueryStringParameters().Item("x")
    Friday, July 20, 2007 6:47 PM
  • One question remains: Where can I find the parameters to Process.Start (for a ClickOnce installed application) ?

     

     

     I assume 'TestingProject' is the name of the project, but what's the location?

     

    Also, localhost is systemwide, while ClickOnce applications are installed per user, so will that work if two users both install the same app?

    Friday, July 20, 2007 8:03 PM
  •  just.a.nerd wrote:

    One question remains: Where can I find the parameters to Process.Start (for a ClickOnce installed application) ?

     

     

     I assume 'TestingProject' is the name of the project, but what's the location?

     

    Also, localhost is systemwide, while ClickOnce applications are installed per user, so will that work if two users both install the same app?



    Its a url.  If internet explorer is your default browser, it opens the browser to the provided location.

    If you were to manually go into IE and type the address "http://localhost/SomeProject/SomeProject.application" it would invoke the app in the same fashion as clicking on the installed shortcut in your programs list. (Hence in code, to ensure internet explorer is opening the link and not another browser, firefox doesn't handle this type of invocation, you can use Process.Start("iexplore", "http://domain/project/project.application?variable=value") and get the same results)

    Localhost is just where my test project is published to provide the example for this explanation.  If you publish to a more public domain, then the url you provide should follow suit.  That is, if after you publish, your publish.htm file is available publically at http://www.yourdomain.com/projectname/publish.htm then the link you provide to the process.start command would be "http://www.yourdomain.com/projectname/projectname.application" with any name/value pairs that you want to pass to the app (in "?name1=value1&name2=value2" fashion).

    FYI.  If you want to use both this method of invocation and the shortcut installed in the Program Files list, your getQueryStringParameters() method should check to see if ApplicationDeployment.CurrentDeployment.ActivationUri is null.  This is because the program files shortcut doesn't provide an activation uri, and will throw a null pointer exception without this check.
    Monday, July 30, 2007 8:43 PM
  • So, basically I'm back to sqare 1! .. or should I say, question 1?

     

    You're talking about web installed applications, while I was asking for locally installed applications

    Wednesday, August 01, 2007 5:16 AM
  • I think this is a solution if anyone is still interested:

    1. In online mode you use your loader program to launch the actual application via iexplore using the url and attaching the argument as part of the url. It is required that your application is started this way at least once.

    2. IExplore will then start your actual application. Your loader program must poll the process list waiting for the actual application to start (using Process.GetProcessesByName). When it hooks into the actual application you can save the path to the mainmodule in you loaders config file.

                    Configuration Config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);  
                    Config.AppSettings.Settings["offlinelocation"].Value = actualappprocess.MainModule.FileName;  
                    Config.Save();   



    3. In offline mode, your loader program uses the value saved in it's config to start the actual exe passing the argument as a normal program argument.

    Theoretically, since the location only changes during an online update, the location will be updated automatically and your offline value should point to the correct file, but i haven't really tested this extensively. Your actual application must be able to check for arguments via the ActivationUri or normal program argument array.

    Tuesday, February 17, 2009 8:55 PM
  • I wonder if it would be possible to pass the information by storing it in a USER scoped environment variable. 
    Sunday, March 08, 2009 12:55 AM