We Keep Coding

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

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?

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().

VSTS Load Testing - How to read runsettings dynamically of currently running load test file

I am running a load test from some xxx.loadtest file and would like read the active run settings section of this xxx.loadtest load test file dynamically for various properties such as Description, Test Iterations, Run Duration etc. Please note that the file name xxx.loadtest keep on changing as I run different set of load tests. So I cannot hardcode that in my code. Is there a easy way to get the full file path of this load test file without having to hardcode the file name ?

Many of the values in the run settings are available via a load test plugin, see here for more about creating them. The code below is an extract from a plugin I wrote, it shows how to access two of the values in the run settings.
public class LoadTestPluginExample : ILoadTestPlugin
{
private LoadTest m_loadTest;
private int warmUpPlusRunDuration;
public void Initialize(LoadTest loadTest)
{
m_loadTest = loadTest;
warmUpPlusRunDuration = m_loadTest.RunSettings.WarmupTime + m_loadTest.RunSettings.RunDuration;
}
... other plugin methods that use warmUpPlusRunDuration
}
I regularly use the intelisense of Visual Studio to explore the values etc that are available in web tests and in load tests.
If you really want to read the .loadtest file itself then the original full filename and file path are probably not available at run time, because the load test is deployed to the execution computer(s). As the original and execution computers may be different then the original path may not be valid during the execution. However, I believe (but I cannot check at the moment) that the .loadtest file is deployed into the (by default) ...\TestResults\{{name+date+time}}\... folders along with the other files for the test. One of those folders is the current directory when the test runs so it should be simple to do a search for .loadtest files in the relevant directory.
The number of agents is available in the AgentCount property from the LoadTestContext and it is one of the named entries the context of a web test when it is executed as part of a load test. That means it can only be accessed via the code of a plugin (or similar) and makes debugging and testing the plugin harder as the LoadTestContext is only available within a load test.

Auto Updating Winform Application Used Over Remote Desktop

We have an app we wrote deployed onto our terminal servers at work, and keeping it up-to-date is a bit of a pain.
What update mechanisms do people use for app on terminal servers? At the moment we manually copy the new exe + dependencies on witch is just rubbish.
I'm a bit concerned about files being locked by users when trying to update, i cant really just kill the process in case someone is in the middle of doing something. We would like to be able to handle the odd fat client update as well.
Ideally we'd plug something into teamcity/octopus but are open to suggestions

Create a script that copies the exe file to a user specific temp folder, then launches the copied exe. To make the script more efficient, you can have it check the dates of the files. If they are different, then you copy the file over the old one located in the temp folder, else you just launch it.

Multiple executable accessing the same folder at the same time

We have a python application that checks a directory(C:\sample\folder) every 5 seconds, there's also this external application(.net app) that puts file into that same directory (C:\sample\folder).
Will there be any conflict when the two application access the same folder at the same time (accidentally)?
Conflicts like :
the external app wont be able to place a file because the python app is currently walking through that same directory?

It should be fine for the external app to create and write to a file. If the Python app is reading a file, the .NET app may not be able to write to it while Python is reading it, without both processes opening the file in a shareable way, however.
Likewise if the Python app is going to start reading the newly-created file, it may either find that it can't do so until the .NET app has finished writing to it, or it may read incomplete data. Again, changes would quite possibly be required to both processes to allow reading at all.
It's worth thoroughly testing all the poosibilities you're concerned about, possibly involving the creation of a "fake" external app which writes to a file very slowly, but opening it in the same way that the real one does.

Rename a running executable (exe) file [duplicate]

This question already has answers here:
Why does rename a loaded .net assembly work?
(3 answers)
Closed 5 years ago.
We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.
My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?
Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.

An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"
Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.
If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.

No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.
And it won't work, anyway. His theory is quite wrong:
Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.
Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.
Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.
See number 1.

In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.
When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.

If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.
Renaming open files is ALWAYS a bad choice!
But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...