I guess that it is related to the 3-layer removal. We need to update a path somewhere.

Of course, we need to fix it but it affects only limited group of users. So, it can't block the 3.5.1 release. So, lower the severity a bit.

A "limited group of users" - actually all those persons doing some kind of programming under Windows using .NET.

After having so many problems in this area with pre 3.4 versions and now again with 3.5 versions I guess, that our company simply will give up (direct) support for this software from our software tools simply due to heavy QA problems in this area.

+1 We are using the SDK in a professional environment as well but with C++, the same error occurs there. If we cannot rely that it works in every version or is at least fixed quickly in the next minor version our company has to abandon libreoffice and recommend our customers either to switch back to openoffice or to microsoft office.

One writer mentioned this error also in:

https://bugs.freedesktop.org/show_bug.cgi?id=46224

hmm, after some debugging it seems binaryurp.uno.dll fails to load, no real info I could see in osl_loadModule either, just no handle returned ( and path is good ) I don't have the windows smarts to detect where else to look for errors
Tried running it in the VS debugger I see that there is nag dialog complaining about msvcp90.dll not being found ( at the point it tries to load binaryurp.uno.dll ). I'm not being familiar with windows but I do know that there are certain security whatnots around loading runtimes etc. I notice that there is a soffice.bin.manifest that contains some dependecy/dependentAssembly nodes relating to this runtime. In fact when I copied the soffice.bin.manifest to csharptestclient.exe.manifest ( to match the csharpclient.exe I was using to test this bug ) it works fine. Perhaps there is a similar solution for some of the .net bridge dll(s) that might get over this problem

Creating such a manifest might be a usable workaround? until a better solution

(In reply to comment #4)
> +1 We are using the SDK in a professional environment as well but with C++, the
> same error occurs there.
and I suppose you reported the bug right?
 If we cannot rely that it works in every version or is
> at least fixed quickly in the next minor version our company has to abandon
> libreoffice
I'd say right now people are shaking in their boots that you might abandon libreoffice. You do realise that libreoffice is a community opensource project, if you expect enterprise level support then you should pay for it. There are companies like Suse, Red Hat and others that employ paid developers, I'm sure they offer paid support too. 
I wonder why do you use opensource at all?, If like you imply you are building software commercially that uses libreoffice then clearly you are developers and should be able to help yourselves. One of the compelling reasons for using opensource is that if and when there are problems then you really can change things, 
 o if there is a bug you can help fix it by debugging, fixing and sending a patch or even just by opening quality bug reports with decent descriptions and steps to reproduce, 
 o if there is a feature gap you can help fill it.
But, sadly it seems you think that using opensource software just you access to free software and and a team of volunteers who will slave over your problem when you demand it 
> and recommend our customers either to switch back to openoffice or
> to microsoft office.
good luck with that :)

seems there might be a build problem, binaryurp has no embedded manifest containing the dependency on VC90 runtime stuff

*** Bug 46682 has been marked as a duplicate of this bug. ***

> I'd say right now people are shaking in their boots that you might abandon
> libreoffice. You do realise that libreoffice is a community opensource project,
> if you expect enterprise level support then you should pay for it.
You are right with everything you say. I was just wondering how Petrs comment was about to be understood: That the SDK is not important enough to be fixed as soon as possible, even if it's a critical bug? In the past we were very fine how things were handled, but if there is a change in the communities opinion concerning the SDK I just want to know. I just got the feeling from here and from the mailing-lists that the SDK is not supported very much anymore.

Noel Power committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3d806be7d30a437607d924a4d33f13fe20dd1ba

fix uno bootstrapping for .NET ( and perhaps c++ ) fdo#46832

Will this fix go also in 3.5.1?

Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6246139df005d6ac4627bc8f4665539effb6e94&g=libreoffice-3-5

fix uno bootstrapping for .NET ( and perhaps c++ ) fdo#46832


It will be available in LibreOffice 3.5.2.

I added Fix submitter as assignee because this will ease queries and bug tracking.

*** Bug 46224 has been marked as a duplicate of this bug. ***

Created attachment 123233 [details]
time

The content of attachment 123233 [details] has been deleted