Is there a way to increase/bypass the limit for ClickOnce deployed activations attempting to load at-CodePudding

I am writing a Crystal Report Viewer in Visual Studios using ClickOnce to deploy updates and install on users computers. I am using Visual Studios C# and have the application checking for updates before loading the program to ensure all users have the latest version when needed.

One thing that I did not think about and just ran into is the number of reports attempting to load at once on a machine. Some users have 10 reports starting simultaneously when they log into our ERP. I made a batch file to start all the reports they needed but I ran into an error:

Too many deployed activations are attempting to load at once

I tried searching for an answer as to how many ClickOnce instances are allowed to load at once and I could not find the answer. It seems to be around is 8 (based on my testing) and apparently it is in place to prevent DOS attacks against the ClickOnce server. I tried waiting a few seconds in the batch file after every 5 reports or so but this is not a long term solution.

Is there a way to increase this limit or should I just open all the reports needed in a single instance from a command? Even if I go with the second option, users can still add reports to automatically open in the ERP causing this issue to arise again. So is there a way to detect how many ClickOnce instances are currently loading and wait for them to finish, allowing me to bypass this issue entirely?

CodePudding user response：

The solution I came up with for this was to expand the command to include multiple reports so all the reports will open under the same program. That way, ClickOnce is only involved once per batch file. Each report runs in its own thread so it behaves the same as running each report as a new instance of the program.

Theoretically a user could add enough batch files to our ERPs auto launch feature to overload the system and receive the same error as before but we could just add that to the batch file once we find out.

Until I find out if there's any way around this limit, this is the best I can come up with since it seems to be happening before the program even hits main().