Go Back

Visual Studio/SDI with a Linux Production Server

I am looking for someone who has a similar development setup as mine. I am using Visual Studio 2022 as my editor (on windows of course), and using the newest SDI. I have a Multi-mainline project and a Subroutine project. My Production server is a RedHat Linux server. My output for my DBRs and ELB is a windows folder.

My problem is - when I run a build in Visual Studio it generates the new DBRs and or ELB and puts them in the windows folder as it is supposed to - then I copy the new DBRs and/or ELB onto my Linux server (using either a windows explorer or a windows batch file). Most every time I do this - if a user is currently using one of the DBRs that I copy over - they will get booted out of that program (usually with a Segment Violation error). With Linux, I am used to being able to recompile programs at will with no interruption to the users - once the user closes that specific program, the next time they start it up it will run the newer version.

Today I had a perfect example as I had to change a subroutine, the build recreates the ELB - if I copy this to the Linux Server it will boot everyone out and they would have to start their session up again - so now I have to wait until evening to release the changes, and then I can test tomorrow and if changes are needed - wait until the next day.

Has anyone done anything like this - and have a better solution for publishing updates to programs? I am contemplating having to go back and resume building my application in Linux instead of using Visual Studio's build.

Thank You
Todd D
CPS, Inc.

3 Answers
0   | Posted by Todd Duininck to Visual Studio Integration on 6/6/2022, 8:20 PM
Steve Ives
Have you tried renaming the original file immediately before copying the new file? I believe existing users will continue to run the renamed image and it may get you around your problem?

6/9/2022, 3:26 PM   0  
Steve Ives
Another thing you might want to consider is setting up your development environment using a Linux instance running on your Windows development system using Windows Subsystem for Linux V2 (WSL2).

By setting up a Linux32 or Linux64 configuration in your Visual Studio environment, you can guarantee that any .defines are processed correctly for the Linux target platform (I'm guessing you already do that part) and because WSL instances can access the Windows file system (and vice versa), it's easy to set up the Linux environment to access the binaries just built with Visual Studio.

This means that builds happen at full speed, and binaries are immediately available for testing from Linux, including using the remote debugger to debug the code running on Linux directly from Visual Studio. It is even possible to run xfServerPlus in the Linux environment and debug your server-side code from Visual Studio also. It really is a sweet development environment for Linux code.

6/16/2022, 5:43 PM   0  
Greg Creme
Hi Todd, 

We have a similar environment to yours where we are compiling in windows and copying to linux.  We have never had any complaints when we are copying new files up to the production servers that they are getting kicked out in the middle of programs, but we may just not be hearing about it if they are.  

However, one thing that we may be doing differently than you is we copy to a staging folder on the production server from our windows machines, when natively on linux, we will copy the files from the staged location to the live location.  Perhaps it is the FTP delay and the file being partially there that is causing the problem for your users?  

I would be interested to hear if doing it this way has any difference in the experience you are having.  

Thanks, 
Greg

6/24/2022, 2:26 PM   0  
Please log in to comment or answer this question.