- This topic has 44 replies, 3 voices, and was last updated 4 months ago by
.
-
Posts
-
Problem solved. My bad, missing MqttNet.dll.
Since I use the .pdb and .deps.json file as identifiers to identify the target dll files and copy them out, the support dlls are not moved to my final build output folder.
What is the recommended way to collect all the necessary files into a clean separate folder after build each solution ? Like your distributed package does ?
I think the VSCode setup here works just fine on Debian 10.
Except that the default wine 5.0.3 doesn’t work with SA. Alwaysstack overflowafter activating any button or menu that actually start to load the xml file.002d:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 002d:trace:loaddll:load_native_dll Loaded L"Z:\\home\\zzz\\repos\\rapidscada6\\scada-v6-master\\ScadaAdmin\\ScadaAdmin\\ScadaAdmin\\bin\\Release\\net6.0-windows\\win-x64\\ScadaWebCommon.Subset.dll" at 0x24cb0000: native 002d:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 002d:trace:loaddll:load_native_dll Loaded L"Z:\\home\\zzz\\repos\\rapidscada6\\scada-v6-master\\ScadaAdmin\\ScadaAdmin\\ScadaAdmin\\bin\\Release\\net6.0-windows\\win-x64\\System.Xml.XmlSerializer.dll" at 0x24ce0000: native 002d:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 002d:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 002d:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 002d:err:seh:setup_exception stack overflow 1584 bytes in thread 002d eip 000000007bcd61d3 esp 0000000000130fe0 stack 0x130000-0x131000-0x2b0000 0035:fixme:console:CONSOLE_DefaultHandler Terminating process 2c on event 0I have other design software using wine 5.0.3. So maybe I just leave it that way and use VM instead.
What is the recommended way to collect all the necessary files into a clean separate folder after build each solution ? Like your distributed package does ?
I created a custom application to collect the files into the package. Not ready to share it. The task also can be solved by writing scripts.
Yeah, I created a dumb script to pack Administrator app based on beta rilis file list but somehow my own build searching for dependency library in the current directory, different than official release from the root of Administrator app.
I even build SCADA 5 on VS Code but still need Visual Studio msbuild tools installed, so still Windows only.
somehow my own build searching for dependency library in the current directory, different than official release from the root of Administrator app
What particular files, for example?
Yeah, I wrote a script for that. But I noticed that some files are missing from the build output. e.g.
web.confg ...some output are not shown in released file
ScadaCommonApp ScadaCommon ScadaServerApp ScadaServer ... AgentClient.dlletc.
ScadaCommon.dll ScadaCommon.Log.dll *Storage.dllare copied multiple times, I tried put them in one ScadaCommon folder, and add
--additionalprobingpath $SCADA_COMMONafterdotnetinExecStartline, this switch works for dotnet dlls, but not all dlls e.g.MQTTNet.dllIf the dependencies are in a central place, with some additionalprobingpath logic in code, maybe packaging could be a lot easier.
I am not a dotnet guy, this core thing is especially new to me. Is there any way to debug current app in VSCode. I mean like set a breakpoint, inspecting some variables etc ?
The API tooltip and Go To Definition command sometimes works, sometimes not, which is really annoying. I have to switch solution back and forth (the pull up menu on button bar) and wait for OminiSharp to finish, only after that the intellisensce seems to again become aware of the classes, methods etc.
Do you guys have this kind of glitches ? Could i5-5300+8G (disk:ssd) to be slow for this type of development?Is there any way to debug current app in VSCode.
As I read, yes. But I haven’t tried debugging in VS Code by myself, because I use Visual Studio. VS Community Edition is free.
Could i5-5300+8G (disk:ssd) to be slow for this type of development?
The computer is good enough.
Nah, until I replace the 500G with 1T or 2T, VS Studio is not my option.
PS I already have it in Win10 VM, a VM that I have always wanted to get rid of.
Win10 VM is a hack of painful experience, sometimes it doesn’t start, sometimes it doesn’t shutdown, always Please wait updating… Don’t shutdown. When its up, it occasionally become the bandwidth hog even when I am on a metered slow link. The built-in virus scanner sometime kicks in when I am compiling sth. and nothing can stop it. Thus I got to occasionally pause the VM.https://github.com/RapidScada/scada-v6/pull/16/commits/6d6d28c5561bf9b56eac7dec7f658af845ab2581 contain launch.json for debugging ScadaAgent.
I found this VSCode Remote Debugging Guide interesting. The Linux boxes I manage are headless, remote debugging will make troubleshooting a lot easier, I think it will give it a try.
ScadaAdmin seems totally dependent on wine version.
I tried wine 5.0.3, 7.0.3, 8.0.2, all stable version. non works.
Luckily wine-staging 8.13 worked, tried to install 7.13, but most of its dependence has aged, it’s really difficult.As suggested in previous posts wine 7.13 should work, but 8.0.2 didn’t. It is quite unexpected for me. 7.0.3 also make SketchUp unable to render any graphic, (it worked flawlessly on 5.0.3). Apparently neither higher version nor stable release guarantees compatibility or less regression.
On all non-functional versions, scadaadmin run into stackoverflow and get stuck before any form is shown. Tried binaries compiled with ReadyToRun flag too no difference.
Tried to find where is this happening on 8.0.3, but stackoverflow kicks in right afternew frmMain()beforefrmMainconstructor is called . Maybe sth went wrong within the CLR. Tried several win desktop runtime: 6.0.11, 6.0.20 non worked. But both works in wine-staging 8.0.13.Install the right wine version. that’s all.
- You must be logged in to reply to this topic.