Support Board
Date/Time: Sat, 23 Nov 2024 02:24:37 +0000
[Programming Help] - VS2022: Pre/Post Build Events DLL Issue
View Count: 632
| [2024-06-23 22:39:14] |
| ondafringe - Posts: 283 |
|
I have an older project built with VS2019 Community that used simple PowerShell scripts in the Pre/Post Build Events so I could update a DLL without having to shutdown and restart SC. It worked without issue, and after updating that project to VS2022 Community, it continues to work without issue: DLL file can be released, updated, and reloaded without having to shut down and restart SC. I created a new project using VS2022, copied my two PowerShell scripts from the old project folder into the new project folder, updated the Pre/Post Build Events to reflect the new location of the PowerShell scripts, and local host and UDP port remained the same. I've tried everything I can think of, but I just can't get it to work. Keep getting the error that the DLL file "can't be opened" or "can't be opened for writing." What I was, and still am, using is what @PeterSt posted in this thread (see Post #21). ACSIL - DLL cannot be opened for writing Here is how things are setup at present, which, except for file names and paths, is the same as what I used before. ReleaseDLL.ps1: $client = new-object net.sockets.udpclient(0)
$peerIP = "127.0.0.1" $peerPort = "22904" $send = [text.encoding]::ascii.getbytes("RELEASE_ALL_DLLS") [void] $client.send($send, $send.length, $peerIP, $peerPort) $client.close() LoadDLL.ps1: $client = new-object net.sockets.udpclient(0)
$peerIP = "127.0.0.1" $peerPort = "22904" $send = [text.encoding]::ascii.getbytes("ALLOW_LOAD_ALL_DLLS") [void] $client.send($send, $send.length, $peerIP, $peerPort) $client.close() Pre-Build Event powershell -executionPolicy bypass -file "D:\Documents\Visual Studio 2022\ProjectFolder\ReleaseDLL.ps1" Post-Build Event powershell -executionPolicy bypass -file "D:\Documents\Visual Studio 2022\ProjectFolder\LoadDLL.ps1" ========================================= I have the latest updates for VS2022 installed, and I'm using the latest version of SC (or very close to the latest version). I've double-checked that the UDP port in SC is still set to 22904. I've run the PowerShell scripts from the Command Line without issues. I can occasionally get it to work if I jump through a number of hoops, such as, close the new project, open the old project, rebuild the old project, close the old project, reopen the new project, and rebuild the new project. Sometimes that works. Sometimes it doesn't. There's bound to be something I've overlooked, or a typo, or who-knows-what, but as of now, I'm stumped. If any of you code gurus who use Visual Studio have any idea as to what the problem could be, please let me know. If worse comes to worse, I'll just have to go back to building from inside SC. Date Time Of Last Edit: 2024-06-24 03:21:58
|
| [2024-06-24 14:38:42] |
| ForgivingComputers.com - Posts: 960 |
|
If worse comes to worse, I'll just have to go back to building from inside SC.
I don't think I can help you. You know way more about VS and Powershell than I do. I have always built from the Analysis>>Build Custom Studies menu. My most frequent error is forgetting to stop debugging before building a new version. Learning what I need to know to create custom studies I have gotten used to doing things one way. For example, I don't understand why I would want to use Projects and Solutions in VS. I have always gotten by with just editing CPP files and saving in VS, then building in Sierra Chart. I know there are way more features of VS than I use. My focus has been editing, debugging, and version control with Git in VS. That was a big step up from debugging with Notepad++ and "print" statements using sc.AddMessageToLog. If using Projects, Solutions, and Build from within VS is beneficial, I would love to hear some of the benefits. What works for me is "good enough", but I am always interested in "more better". |
| [2024-06-24 16:00:31] |
| ondafringe - Posts: 283 |
|
And I know very little! lol For the past five years, like you, I've also been using Analysis>Build Custom Studies DLL and it has worked fine for me, as well. I've used VS many, many years ago on projects unrelated to SC and just wanted to look into an alternative approach. So far it hasn't worked out and I have moved back to building from within SC. However, unfortunately, that short detour with VS has introduced another problem: I can no longer build a debug version from within SC. It will build a release version, but not a debug version. Or it is building a debug version, but my breakpoints aren't breaking code execution. Weird. Not sure what's going on, either the attachment process isn't working, or what? I D/L'ed the current version of SC, and shutdown and restarted VS, but that didn't help. Without a debug version, I'm in trouble. As far as what additional benefits VS brings to the table, not sure about this, but I think a more lengthy and complicated study would benefit from the ability to add class objects, structures, etc. in order to more compartmentalize and streamline your code. But don't quote me on that. :) Date Time Of Last Edit: 2024-06-24 20:52:35
|
| [2024-06-25 00:39:46] |
| ondafringe - Posts: 283 |
|
Ok, it took me awhile to figure out what was going on. And just to update this, not that anyone else will find themselves in this situation. Once you use VS, you *can* go back to building within SC. 1. Click Analysis > Studies and remove your VS-Created study from the list 2. Click Analysis > Build Custom Studies DLL > Build > Release All DLLs and Deny Load 3. Delete all four files (VS creates 4 files) associated with your DLL from the SierraChart\Data\ folder. 4. Click Analysis > Build Custom Studies DLL > Build > Allow Load DLLs 5. Rebuild your study from within SC 6. Click Analysis > Studies and re-add your study Once you do all that, you should now be able to build using SC again the way you usually do. ======================================================== Even though I can't get my Pre-Build Event script to release the DLL for update, what I could do is: 1. Step #2, above 2. Build my study from within VS 3. Step #4, above 4. Analysis > Studies > OK ========================================================= At least I now have options. :) Oh, I did notice something different about the two different DLLs: The one created by VS was name.dll, but the one created by SC was name_64.dll. Apparently, that doesn't make any difference. Date Time Of Last Edit: 2024-06-25 17:24:30
|
| [2024-06-25 01:06:10] |
| ForgivingComputers.com - Posts: 960 |
|
I only do 1, 5, and 6 1. Click Analysis > Studies and remove your VS-Created study from the list
5. Rebuild your study from within SC 6. Click Analysis > Studies and re-add your study And if nothing changed in SetDefaults, I only do step 5 and a Ctrl-Ins (Recalc) or Replay in BackTest. Date Time Of Last Edit: 2024-06-25 01:06:39
|
| [2024-06-25 01:09:56] |
| ondafringe - Posts: 283 |
|
I'm pretty much back to using SC, although it was an interesting side excursion!
|
| [2024-07-08 16:53:53] |
| ondafringe - Posts: 283 |
|
Okay, let me finish this thread by saying, I solved my Pre-/Post-Build issues and everything is working to my satisfaction. And just in case someone who wants to use VS runs across this thread in the future, here is the overview. As mentioned, above, the problem was, when running the release-DLL PowerShell (PS) script from the Pre-Build event within VS, the script ran without error, but SC did not release the DLL, so the DLL could not be opened for writing/updating. But when I manually opened a PS window and manually ran the script from there, it worked as expected. I couldn't figure out what was going on, but after a lot of digging around, reaching out on Microsoft's Visual Studio Developer Forum, etc., I did gather enough information to get me across the finish line. It seems VS needs an extension to successfully run PS scripts. Plus, I am running Win10 Pro and was still using PS version 5.1 and, from what I could tell, I needed at least version 6. So, in VS, I installed the PS extension, and I downloaded/installed the latest version of PS (as of this post, version 7.x). Then, in the Pre- and Post-Build events in VS, I ran the PS script in the most basic way (without the need to bypass any PS Execution Policies). The script ran without error, SC released the DLL, the DLL was deployed/updated, and then SC reloaded the DLL. That was it. The changes took effect immediately. Nothing else had to be done in SC (unless something was changed in Set Defaults) -- and that includes not having to: Analysis>Build Custom Studies DLL>Build>Release All DLLs and Deny Load. Now that VS is setup properly, it is actually a little faster (fewer clicks) to create/build/edit/deploy my custom study DLLs using VS than it is to do all that within SC -- one click on Build and it's a done deal. Date Time Of Last Edit: 2024-07-08 17:26:51
|
| [2024-08-11 15:10:24] |
| ondafringe - Posts: 283 |
|
Someone asked me about all this, so here are the step-by-step instructions that I took in order to set up my custom study project using Visual Studio 2022. Note: If you are only using Visual Studio as an editor, and you are doing your build from within Sierra Chart, or you are using VSCode, the following -- may not/probably won't -- work. As far as I know, you have to create your custom study project from scratch for the following set up instructions to apply. If you want to know how to create a project from scratch using Visual Studio 2022, let me know and I will write up and post those instructions, as well. • In “Solution Explorer,” right-click on your project name, and at the very bottom, click on “Properties” • Under “Configuration Properties > General > Output Directory” • Provide the path to the Sierra Chart “Data” folder (usually C:\SierraChart\Data\) • Under “Linker > General > Output File” • Provide the same path to the Sierra Chart “Data” folder and add $(TargetName)$(TargetExt) • That usually results in C:\SierraChart\Data\$(TargetName)$(TargetExt) In order to use Visual Studio to create a custom study to run in Sierra Chart, it is necessary to update your study’s “dll” file without having to close and reopen Sierra Chart and without having to invoke the “Release All DLLs and Deny Load” in Sierra Chart. Visual Studio has Pre-Build and Post-Build Events you can use to facilitate those updates. You will need: • Windows Powershell Version 6 (or higher) • Powershell Tools for Visual Studio 2022 As I understand, all versions of Windows, including Windows 11, only have Version 5.1 (or earlier) installed. To check your version, open Powershell and, at the prompt, type: $PSVersionTable :and press Enter. If you need to download and install the most recent version of Windows Powershell, the following download link was good as of 2024-08-11. https://github.com/PowerShell/PowerShell/releases/download/v7.4.4/PowerShell-7.4.4-win-x64.zip To install the “Powershell Tools for Visual Studio 2022” extension. At the top of Visual Studio: • Click “Extensions” • Click “Manage Extensions” • When the Extension Manager opens, search for “Powershell Tools” • You should see “Powershell Tools for Visual Studio 2022” in the results • Click on that extension, and, at the top of the adjacent pane, click Install Once you have Powershell and the Powershell Tools extension installed: • In Visual Studio, go to “Solution Explorer,” right-click on your project name, and at the very bottom, click on “Properties” • Under “Build Events > Pre-Build Event > Command Line” • Put this: {full path to the powershell .exe file} -File "ReleaseDLL.ps1" • Example: C:\Powershell\powershell.exe -File "ReleaseDLL.ps1" • Under “Build Events > Post-Build Event > Comand Line” • Put this: {full path to the powershell .exe} -File "ReloadeDLL.ps1" • Example: C:\Powershell\powershell.exe -File "ReloadDLL.ps1" • Click “Okay” to exit At the top of Visual Studio, change “Debug” to “Release” – or vice versa – and repeat the above steps. Note: if you are using the default PowerShell that was installed with Windows, you may not need to provide the full path to Powershell. I have attached the two Powershell script files; download and put them in the project folder. Open each file using any text editor and change “your.dll” to the name of your DLL. If you put the ReleaseDLL.ps1 and ReloadDLL.ps1 files in a folder other than the project folder, you will have to provide the full path to those two files in the pre-/post-build events, above. Make certain you set your Sierra Chart UDP port to the same port indicated in the two Powershell script files: • Gobal Settings > Sierra Chart Server Settings > UDP Port The UDP port doesn't have to be the same port I used, just make certain the port you use is the same in all three places. Hopefully, all this will work for you, as it did for me. Date Time Of Last Edit: 2024-09-10 21:01:56
|
 ReleaseDLL.ps1 - Attached On 2024-08-11 15:15:08 UTC - Size: 276 B - 131 views ReloadDLL.ps1 - Attached On 2024-08-11 15:15:16 UTC - Size: 281 B - 104 views |
| [2024-09-10 19:28:32] |
| User333366 - Posts: 10 |
|
You are a genius!!! this worked with the following tweaks - it complained about the two power shell files not being digitally signed. You had to go in the windows explorer, right click, select properties and unblock the file - somehow my project was set up to generate an exe rather than a dll |
| [2024-09-10 20:53:54] |
| ondafringe - Posts: 283 |
|
If you aren't generating a DLL file, you probably didn't create your project correctly. Let me know if you want me to post a step-by-step on how I create a new, custom study project in Visual Studio that generates a DLL, instead of an EXE. BTW, thank you. Trying to figure all that out almost broke my brain! lol Date Time Of Last Edit: 2024-09-11 16:58:06
|
To post a message in this thread, you need to log in with your Sierra Chart account: