Hossein: any idea about this?

(In reply to Buovjaga from comment #1)
> Hossein: any idea about this?

They should bisect the problem using their .Net application, no?

That's true as well.

Marten: can you give it a shot with the win64-25.2 repository (as it stopped working within 24.8 minor versions, it must be a backport from 25.2)?

https://wiki.documentfoundation.org/QA/Bibisect
https://wiki.documentfoundation.org/QA/Bibisect/Windows
https://wiki.documentfoundation.org/QA/Bibisect/Bibisecting_tutorial

(In reply to marten from comment #0)
> It works up to 24.8.4.2, after that (the 24.8 line or the 25.x line) it is not
> working any more (I tried 24.8.5.x and 25.x). LibreWriter is starting, but
> after that the connectivity crashes. No more information available right now
> - we make a reinstallation of the 24.8.4.2 and disable the automatic update.
For the moment, I can also recommend using the older LibreOffice version that works for you, as you've just mentioned.

For the bug itself, I think some stack trace is needed to diagnose the issue of the program crashing. Can you run your program in debug mode? That may help.

Please note that now we have an updated version of .NET binding with LibreOffice that works with cross platform .NET.

But the old LibreOffice .NET CLI support is not changed much during the upgrade, beyond an option to disable it at build time, which should not have any effect on LibreOffice that is compiled with CLI support. There are some other small change in cli_ure/ though.

(In reply to Buovjaga from comment #1)
> Hossein: any idea about this?
I think it can be even related to some other changes. As said, stack trace is needed.

(In reply to Roman Kuznetsov from comment #2)
> They should bisect the problem using their .Net application, no?
That should be possible. Required DLL files are available in LibreOffice bibisect repos for Windows

https://bibisect.libreoffice.org/win64-25.8

Here's a link to have a backtrace on Windows:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace

(In reply to Julien Nabet from comment #5)
> Here's a link to have a backtrace on Windows:
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:
> _How_to_get_a_backtrace

@marten:
The description needs clarification:

(In reply to marten from comment #0)
> CLI connectivity crashes when starting building the reports (so LibreWriter IS starting and appears".

What actually crashes here? LibreOffice process? Some point in the connectivity DLLs? Or, your .NET program itself?

So, two days after my event I had to look at that code crashing and it is this code, which crashed

 XText aXText = OOTextDocHelper.mxDocument.getText();
 XTextRange aTextRange = aXText.getEnd();
 XPropertySet propSet = (XPropertySet)aTextRange;
 propSet.setPropertyValue("ParaStyleName", new Any(style));

So, two days after my event I had to look at that code crashing and it is this code, which crashed

 XText aXText = OOTextDocHelper.mxDocument.getText();
 XTextRange aTextRange = aXText.getEnd();
 XPropertySet propSet = (XPropertySet)aTextRange;
 propSet.setPropertyValue("ParaStyleName", new Any(style));

and style has the value "Überschrift 1" and it throws an uniodl.com.sun.star.lang.IllegalArgumentException.

propSet.setPropertyValue("ParaStyleName", new Any(style));

this statement throws the exception - just to be more precise.

Ok, the reason is "Überschrift 1". In the "older" versions (of the CLI interface) one could use the NLS-named of the styles, but the newer ones seems to need the english named styles.

So "Heading 1" works, "Überschrift 1" does NOT work any more. I remember when writing this code, that I thought how to write NLS independent code here ..

So, is this a bug or feature ?

(In reply to marten from comment #10)
> Ok, the reason is "Überschrift 1". In the "older" versions (of the CLI
> interface) one could use the NLS-named of the styles, but the newer ones
> seems to need the english named styles.
> 
> So "Heading 1" works, "Überschrift 1" does NOT work any more. I remember
> when writing this code, that I thought how to write NLS independent code
> here ..
> 
> So, is this a bug or feature ?

See my comment 3 for how you can answer your own question. Let me know, if you need assistance (like in a screensharing call).

Actually I read it ... and I had to admit, that this is quite nice ... even though I do not understand all of it.

But my first thought was - how can I instruct my program to use these development builds - I have to use the cli_* libraries and they started the installed versions of the product ...

So, how does it help me ?

I tried to reference the specific cli* libraries in my source code, but that gives me an OLE exception ( I assume a security exception)

So, here is a reducded source code from my application showing the problem

namespace ConsoleApp1
{
    internal class Program
    {

        public static  XComponentContext m_xContext;
        public static  XMultiServiceFactory mxMSFactory;


        static void Main(string[] args)
        {
            m_xContext = uno.util.Bootstrap.bootstrap();
            mxMSFactory = (m_xContext != null) ? (XMultiServiceFactory)m_xContext.getServiceManager() : null;

            var propValues = new PropertyValue[1];
            propValues[0] = new PropertyValue { Name = "Hidden", Value = new Any(false) };
            var aLoader = (XComponentLoader) mxMSFactory.createInstance("com.sun.star.frame.Desktop");
            var mxDocument = (XTextDocument) aLoader.loadComponentFromURL(string.IsNullOrEmpty("") ? "private:factory/swriter" : "", "_blank", 0, propValues);


            XText aXText = mxDocument.getText();
            XTextRange aTextRange = aXText.getEnd();
            XPropertySet propSet = (XPropertySet)aTextRange;
            propSet.setPropertyValue("ParaStyleName", new Any("Überschrift 1"));
            //propSet.setPropertyValue("ParaStyleName", new Any("Heading 1"));
        }
    }
}

(In reply to marten from comment #12)
> Actually I read it ... and I had to admit, that this is quite nice ... even
> though I do not understand all of it.
> 
> But my first thought was - how can I instruct my program to use these
> development builds - I have to use the cli_* libraries and they started the
> installed versions of the product ...
> 
> So, how does it help me ?

Ok, I admit I never bibisected any SDK thing.

(In reply to marten from comment #13)
> I tried to reference the specific cli* libraries in my source code, but that
> gives me an OLE exception ( I assume a security exception)

In short, you need to:

1. Create a minimal reproducer program, which you have already created.
2. Create a make file or some build environment that uses the .NET binding files specific to the bibisect repo folder instead of normal LibreOffice installation.
3. Do bibisect, and build and test your program for crash, either manually or automated:
https://dev.blog.documentfoundation.org/2021/10/14/automated-bibisect-to-find-source-of-a-bug/

Ok, then I am out

Marten: I discussed this issue in the developer chat and got feedback that this seems related to a recent style UIName rework that changed API semantics - https://gerrit.libreoffice.org/c/core/+/178087 & https://gerrit.libreoffice.org/c/core/+/177858

So from what I understand you should be able to tweak your code a bit and make it work.

Remember that professional help is available:
https://www.libreoffice.org/get-help/professional-support/

For reference:
Based on the description in comment 10, I did a bisection using the Japanese UI and a BASIC macro that applies the "見出し1" style, and this was the first bad commit.

commit 5917ef4d57ca5869ae3bb419093882e491c06574

(In reply to Saburo from comment #19)
> For reference:
> Based on the description in comment 10, I did a bisection using the Japanese
> UI and a BASIC macro that applies the "見出し1" style, and this was the first
> bad commit.
> 
> commit 5917ef4d57ca5869ae3bb419093882e491c06574

Thanks a lot for the precise find.

Marten: as it seems you have all the information needed to adjust your code after the API change, I will close this. I recommend to look into learning bibisecting as it gives you superpowers in troubleshooting. In the best case you will find the cause of an issue in 10 minutes. I am available for teaching, as mentioned.

unfortunately there was a very non-obvious data-loss problem caused by some previous version renaming a built-in style, and the UNO API implementation accepting localised style names in a very poorly thought out and inconsistent way.

we generally try to keep the UNO API compatible, but because the ODF import uses the UNO API, the only way to fix that was that the UNO API implementation no longer accepts localised style names of built-in styles.

this is documented in release notes for 25.2:

https://wiki.documentfoundation.org/ReleaseNotes/25.2#API_Changes

but then it was partially backported to the 24.8 branch (only the part that's required to fix the known problem) and forgotten to add it to the old release notes, have added it now:

https://wiki.documentfoundation.org/ReleaseNotes/24.8#API_Changes

note that 24.8 only changes behavior for paragraph styles, and the other styles change behavior in 25.2.

To summarize:

Below code was working before, only in German environment, and was causing issues if LibreOffice language was anything other than German:
 
    propSet.setPropertyValue("ParaStyleName", new Any("Überschrift 1"));

Now, in LibreOffice 24.8.5* and LibreOffice 25.2** or newer, only internal names like "Heading 1" should be used. Therefore, this is the correct code now:

    propSet.setPropertyValue("ParaStyleName", new Any("Heading 1"));

Simply do this change if you use localized names for the styles:

"Überschrift 1" -> "Heading 1"   // German
"見出し1"        -> "Heading 1"   // Japanese
...

* paragraph styles
** everything else