Prevent the mapping of objects with a data length of 0 bytes

[trojanobelix]

project.zip
Prevent the mapping of objects with a data length of 0 bytes.

The importer should prevent string objects with a data length of 0 from being imported.
In my opinion, string types without a defined length are formally allowed according to DS301, but:

• they cannot be mapped to PDO
• they cannot be used effectively
• the editor should ignore them

ToDo:
Object 0x2000 in the OD is formally correct IMHO, but is created in the CANopen Editor with a data length of 0; for strings, the data length should be initialized to 1.

[henri62]

Do you have a pre-built version with this fix in it? (Or with other fixes from the development branch latest commit).
I do not have an environment to build it myself.

On the top github page here the latest and only release is old. Maybe time to update it?

[trojanobelix]

(Files deleted: New files later in this thread)

Do you have a pre-built version with this fix in it? (Or with other fixes from the development branch latest commit). I do not have an environment to build it myself.

On the top github page here the latest and only release is old. Maybe time to update it?

Here is the binary file for Windows. Unfortunately, I can't test it on Linux.

[henri62]

The windows build is ok for me, but the version does not run, it asks for the .NET runtime. I tried different versions of the runtime but it always refuses to run.
The previous version I have on my system (the only official release) still runs.
To which runtime is this version compiled?

[trojanobelix]

To which runtime is this version compiled?
.net 8.0

[henri62]

That is strange, it will not run at all (I have also the .NET 8.0.22 runtime). I also tried to copy over all files in the existing (running) tool to a new directory, copy over the files in the zip and rename it to the original name. Still not running.
It looks like visual studio 2017 is used for the project, maybe I can try to build it myself?

-edit- VS2017 does not seem to be available any more, what is recommended to use, if I want to build it myself?
-edit- I gave up to build it myself, running in to many problems with nuget packages and the libEDSsharp.dll where the sources are missing from. Its unclear to me where it should come from?

[trojanobelix]

I use 2026, latest version

[trojanobelix]

Here is the new binary file for Windows. Unfortunately, I can't test it on Linux.
CANopenEditor_net8.0-windows.zip

[trojanobelix]

.net8.0

[henri62]

Did not have time yet to test it, next week or so I need to change some things in my project. So then I will try it and give feedback.

[henri62]

I unzipped the CANopenEditor_net8.0-windows.zip and tried to run EDSEditor,exe file but it does not do anything. I try to run it on W11.
It displays nothing, just exits. The event log in windows shows this:

Application: EDSEditor.exe
CoreCLR Version: 8.0.2726.22922
.NET Version: 8.0.27
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Drawing.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at ODEditor.ODEditor_MainForm..ctor()
at ODEditor.Program.Main()

-edit- It seems that some dependent DLL's are not in the zip files. Also System.Configuration.ConfigurationManager.dll is missing for example.

[trojanobelix]

net8.0-windows.zip
Okay, let's try again. With the switch to .NET 8, System.Drawing is deprecated and no longer included. So it has to be added via NuGet; I've added that.

Setting true ensures that all DLLs coming from NuGet are placed in the build directory. It should work now.

This makes the package quite large. There might be a more elegant way to do this, but to keep us moving forward, let’s go with a quick-and-dirty solution for now.

[henri62]

I tried it out and it works for me now, all DLL's are found. Actually, the original release also contains way more files as the first zip file you posted, such as: a lot of language directories and other DLL's. As far as I could find you should package any dependent nuget-package in the installer package.
So the quick-and-dirty solution is not such a big issue.
It could be that you have to specifically add the system dependencies and exact version somewhere in a json file, but you still have a dependency to old .net frameworks which eventually may break in the future or give annoyances.

So now back to the orignal problem: Which bug should this PR solve exactly? I can test it for you, so you can integrate the fix.

PR #211 is not related I think, at least I tried to reproduce that specific problem but something else is going on there. I will continue in the 211 to avoid pollution of this thread.