Looking for feedback on file size, installation process, etc.

[bitbound]

As you may have noticed, the file sizes for the clients have increased after the move to .NET 5. I was hoping it would be the opposite. Microsoft had been talking about improvements to the Trim feature, which can be used to remove unused assemblies from a deployment and decrease the file size.

But the Trim feature in .NET 5 ended up breaking Remotely because it started removing required assemblies. I found a workaround for it, but I'm hesitant to turn it back on. And the file size reduction isn't really any improvement over .NET Core 3.1.

For those who aren't aware, the file sizes for the apps are so large because they are self-contained deployments. That means, they include the entire .NET runtime with them, so it doesn't have to be installed by the user. Older .NET Framework apps were so small because .NET Framework is installed with Windows.

Similar to .NET Framework apps, .NET Core/.NET 5 apps that aren't self-contained (called framework-dependent deploys, which is confusing because of .NET Framework/.NET Core difference) won't run if the correct version of the runtime isn't installed on the computer. You can read more about it here: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent

In the past, I've tried doing framework-dependent deployments by having the installer (which is a .NET Framework app) detect if the correct version of .NET Core is installed and downloading/installing it if it's not. But it's too error-prone. There are many reasons why the download/install might fail. This could be really bad when agents are auto-updating. If the new version requires an updated version of the runtime, and something caused it to fail, it could cause all the agents to drop offline permanently someone physically installed the runtime and agent again.

Recently, Microsoft has started deploying updates to .NET Core and .NET 5 installations (if it's already been installed). This makes me feel a little more confident about doing runtime-dependent deployments again.

With .NET 5, they also ported over an old deployment technology called ClickOnce. It creates a small setup bootstrapper that downloads the application files and installs it in the user's %localappdata% folder. They can also install the .NET 5 runtime and auto-update themselves from a specified server. Since it installs the the runtime, the Remotely download would be way smaller.

They can't install services, though, and they only run non-elevated.

My idea is to use to create a ClickOnce installer for the Desktop app. So an end user installs that, and now they have .NET 5 (which Windows will now keep up-to-date) and Remotely quick support (which will auto-update). Then I'd create a button or whatever in the quick support app to install the service. It'd launch a new process (I'd probably repurpose the existing installer for this) with elevated rights (so UAC would prompt), and the service would get installed too.

Or they could just leave the quick support installed for infrequent attended access.

The only way for that this will work, though, is if the Remotely server URL is hard-coded into it. That means that everyone would need to build it themselves, and I couldn't supply the ZIP packages in GitHub releases anymore.

I've actually been wanting to this anyway, because having to enter URLs is a horrible customer experience. One time, I tried appending the server URL to the end of the EXE on-the-fly as the file is being downloaded, since the server is aware of the request URL. It works, but it breaks the digital signature. I've read about ways of getting around that, but it's pretty complicated, and I haven't gotten it to work.

I'm not sure if I'd face backlash by making it mandatory for people to build Remotely. I tried to make it easier by creating GitHub Actions workflows to automate it. All someone needs to do is plug in some variables and hit run. And if people were interested, I could recreate my Azure Pipelines jobs in YML so they can be shared. It may seem daunting at first if you've never set up a build pipeline, but doing so pays off a thousand fold. You just press a button, and you have the latest version deployed to your server, and all your agents automatically update.

So, with all that said, what are your thoughts on this? Specifically about the ClickOnce installer and that whole process. And then about the self-build requirement.

Cheers!

[Fimeg]

The self build is documented well enough that anyone who's gotten this far can follow through and get it done, IMO.

[swilkey]

I can say that if the requirement had been for self build I might never have implemented it as it would be a barrier that would require commitment of a greater amount of time before I could really test it in my environment and therefore this would have gone to the bottom of my priority list to look at. Stephen

…

On Sat, Jan 16, 2021, 7:33 PM Fimeg ***@***.***> wrote: The self build is documented well enough that anyone who's gotten this far can follow through and get it done, IMO. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#197 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5UXTE5TNU7IBYJOI576ELS2GTCXANCNFSM4VIQTL7A> .

[imnotjack91]

I don't know how to self build and am currently struggling with server deployment. (probably because I did not self build that yet) so IMO, techs aren't necessarily developers or have any programming knowledge whatsoever. Could you set up a build gui in the server admin page itself? So the admin only has to hit a button to generate client installers after the deployment is complete?

[bitbound]

@swilkey That's a valid point. Thanks for the feedback.

@imnotjack91 Hosting your own web app can be complicated, especially when there are databases, client apps, and other such details to worry about. There really isn't any way around that. There isn't any programming knowledge required to build it, though. You just need to install some things and run a PowerShell script. If you're using the GitHub Actions, you just need to enter some variables and click the run button.

Unfortunately, having the server build the clients on demand via a GUI is not as simple as it sounds. Here are the technical issues that would need to be solved:

• The clients can only be built on Windows. The vast majority of people are running their servers on Linux.
  • One option is to only have the feature work on Windows Server.
  • Or I could create a web service that everyone's individual server would call out to to perform the build, then return the file.
  • This is how other companies like TeamViewer do it.
  • But building the service would take a lot of time and cost a lot to host, since it would need to serve everyone.
• Assuming the feature is built into Remotely and only works on Windows, I'd still have to create a separate Windows Service project.
  • The ASP.NET Core server itself couldn't do the build given its limited permissions (in most cases). It's not recommended to run the web app process at a permission level high enough to do the builds.
  • It would need to communicate over Named Pipes with a separate Windows Service running as SYSTEM.
  • The Windows Service would do the build and return the output to the server.
  • All this would take a long time.
• I'd also need to verify/install the correct version of the .NET SDK, Git, and maybe some other tools.
• I'd need to handle concurrency and such, so only one build could be triggered at once.

Whichever route I went, it would be a pretty sizable amount of work that I'd be doing for free. If I were getting paid to work on this full-time, and I could spend 9 hours a day on it, then I'd have no issues adding this. As well as custom branding, scripting library, Mac agent, and all the other features I wish I had time to make.

However, I've simply reached the point where I'm not willing to sacrifice that much time from my family (and my own personal rest time). :(

[unravvel]

On the topic of the pre-filled server url and self-building, is it possible to have the agent read the value from a text-based config file that is included with the installer executable, or deployed by the installer? I suppose that the answer is 'no' since if that were the case this probably would have been done already. However I'm speaking with no experience as a developer.

I have seen some other remote access solutions for Windows using an MSI package. They provide instructions and a utility for administrators to edit their installation MSI with a custom server url, among other possible customizations. Do you think using MSI would be a good way to solve the custom server url for Remotely?

[unravvel]

Ah, sorry. With further investigation and trial it looks like the other remote access solution that offers a customizable MSI is using the same process you mentioned for TeamViewer, where they are running the agent compilation in their cloud and providing a signed installer with your customizations baked in.