Webclient: application with Telerik controls => Could not

Posted by DenDuze on 28-Mar-2018 09:17

I have some screens with Telerik controls on it (example radGridview).
This works fine in development but when we deploy the application (WebClient) then I get the error 'Could not load file or assembly ...'.
The assemblies.xml is located in the root of my application
The Telerik dll's are also located in the root of my application
The version of the dll's are the same as the ones in the assemblies.xml and also the same as the ones I compiled my code with.

I've activated the binding-logging (somewhat the same as fuslogvw.exe) but it's not clear to me how this works.
I've only activated the logging with LogFailures-, LogResourceBinds-flag and LogPath (so no ForceLog-flag is used)
When I start my application I get a directory 'Default' under my LogPath.
Under that 'Default'-directory there are 2 directories created (prowc.exe and OE Application)
When I look to the prowc.exe directory (progress webclient) I see a file for that RadGridView what means that there is a problem there - the problem is that the file could not be found because this searches the webclient\11.7\bin directory and my dll-file is not located there - so that  is normal (I guess)
When I look at the OE application directory I can not find a file with RadGridView whatt means that the dll-file is found (in my application directory) - What is correct (I have verified that with the ForceLog-flag).

But when I run the specific screen in my application I still get the error "Could not load file or assembly ...." so I guess the binding of the prowc.exe occurs. Why is that? Isn't there some way to use the binding of the OE Application.

Probably some things I wrote here are not clear but I really do not understand how this works - far from how I can solve this.
I already tried to read the Microsoft Docs regarding this binding but again that is not clear to me.
Can someone help with this?

When I put the dll under the webclient\11.7\bin then everything works (uses the prowc.exe binding) but we do not want to do that.
How can I fix this in a webclient installation?


All Replies

Posted by Laura Stern on 28-Mar-2018 10:56

It seems strange that this should work during development but not at run-time.

When you run from r-code, we don't even need the assemblies.xml file because the assembly-qualified name of all referenced classes are in the r-code.  Though you still can use the .xml file.  So you could try using -assemblies to point at an assemblies.xml in your app directory.  I don't remember if the current-working-directory is one of the places .NET looks for assemblies or if it is only where we look for them, when loading via the .xml file.

Fact that may be of interest: When the AVM loads assemblies from the assemblies.xml file, if there is one that fails to load, we do NOT give an error message.  We just keep going and try to load the rest.  So if you are seeing an error it is because the .NET run-time cannot find the assembly you are referencing in the r-code based on its assembly-qualified name -  or that one of its dependencies is missing.  But since it works when the .dlls are in $DLC/bin, that means the dependencies are there.

You could also try to use the tool fuslogvw.exe.  I've never used it myself, but I believe it will help you determine where .NET is looking for assemblies, so you will know why it is not finding them.

Posted by DenDuze on 29-Mar-2018 00:53

Hi Laura,

That's new! I thought the assemblies.xml was always needed...

I already tried with the -assemblies startup-parameter but still the same.

Yes the dependancies are there and also the dll exists (with the same version and culture) in the root of the application.

The problem with fuslogvw.exe is that it's a part of the SDK and we do not want to install that SDK on production environments. That's why I use the registry solution to output the binding information to disk.

But like I said I do not really understand how that works because there are 2 directories where the output goes to, a prowc.exe and a OE application directory.

In the prowc.exe directory I get an error-file for all bindings (Telerik, Infragistics, ...) - what's normal because it only searches the $DLC\bin and the dll's are not there

In the OE application I ony get a few error-files (but these are not important for me, they are about some Telerik-theme's, the dll's that I use in my screens are correct.

So why do i get the "could not load file or assemblies ..." when starting the screen.

Isn't there some setting to give a search-path to find the dll's for the bindings?

I found something like a prowc.exe.config on the web but I can't make that to work (or must that file have another name).



Posted by PeterWokke on 29-Mar-2018 01:18

Hello Didier,

I use 3party DLL in web clients.

During development I add them to the assemblies.xml.

I distribute the assemblies.xml and the DLLs in the same directory.

In my case names assemblies, a subfolder in the root of my webclient application.

In the startup parameter file I point the -assemblies to this directory.

Other options are to register the DLLs on the client machine.

Extra work and not flexible whe you need to update or add new DLLs to the webclient.



Posted by DenDuze on 29-Mar-2018 01:55

Hi Peter,

Yes, I do the same (except for the -assemblies parameter because the dll's are in the root-directory of our application).

I have no idea why it not works with this dll (Telerik.WinControls.ChartView.dll).

I tried many things already but it always complains that the file could not be found.

If I put the file under $DLC/bin (for testing) it just works.

That's why I tried that logging of the bindings but that just confuses me more and more.

Also tried with an assemblies.config and a prowc.exe.config (like in some Microsoft docs) but nothing works.



Posted by PeterWokke on 29-Mar-2018 05:18


I had the same problem.

After I moved the DLL,s to the folder where the assemblies.xml is it worked.

In your case you could move the assemblies.xml to the root-directory as well.

Point the it in the start-up parameter file.

Basically the systems looks at global installed dll files.

And can look at local dll files.

The local once it can find them when they are in the same folder as the assemblies.xml is.

On the Telerik WinControls I have not tried it. Those controls frequently update while the Progress version does not.

The versions you use on development (compile) are they still the same as you distribute?

That can be the issue as well.


Posted by DenDuze on 29-Mar-2018 07:53

Hi Peter,

My correct dll's and my assembies are in the root of my application.

I tried with and without the -assemblies startup-parameter, both with the same result.

Yes the compiled version and the version in my application directory and in the assemblies.xml are the same.



Posted by Laura Stern on 29-Mar-2018 08:19

I think you're going to have to use fuslogvw to figure it out.  If you don't want to install the whole SDK, just copy what you need from some other machine.  You probably just need the .exe file.  

Posted by DenDuze on 29-Mar-2018 08:43

Hi Laura,

Already done that, you need exe and dll.

But really this does the same as what I already did with the logging of the bindings.

The only difference is that this is a GUI of those logs (from cache) and you can set some properties so the logging gets done on disc (and those settings are the ones that I already used in the registry).

In that GUI fuslogvw:

I see also the OE application where the ChartView binding is succesfull (because the Appbase = <the root of my application>

I also see a prowc.exe where the ChartView binding failed (because the Appbase = $DLC\bin)

So completly the same as I mentioned before.

But what those prowc.exe-entries and thos OE application-entries mean and which are used by my application is unclear to me. I guess the prowc.exe-entries are used because it does not work and if i put the dll under $DLC\bin (what we do not want to do) it works without a problem.

Do you know if we can manage another behaviour with the prowc.exe.config of with the prowc.exe.manifest (or better with some other file that is not under $DLC\bin)



Posted by Laura Stern on 29-Mar-2018 12:41

Sorry, I've never used fuslogvw, so I don't know what it shows you.  And I don't understand what you said before about the "bindings" and logs other than you got some error-files that you think aren't relevant.  

You could try procmon instead - which can show you all the files the process is trying to access.  What we need to see is where Microsoft is looking for the dlls.  You could look at the case that works and then the case that doesn't work and see what's different.  Without help from some kind of tool, I don't think I can help you.

And maybe someone more experienced with fuslogvw can pipe in here.

Posted by DenDuze on 30-Mar-2018 00:57

Hi Laura,

Thanks for your input.

What I mean with the logging of the bindings is the following:

fuslogvw.exe is just a viewer for the logging of the bindings that are normally in cache (so default these are not written to disk). With fuslogvw.exe you can enable the writting of those bindings to disc.

What I did (after searching on the web) is enabling that same logging to disc by setting some keys in the registry (so what fuslogvw.exe would do if you set on the logging).

In fact I find it easier to use a tail program with the log-files then using the GUI fuslogvw.

I know where the dll's are searched, it's in the $DLC\bin.

I just do not know/understand how why or how to change that behaviour.

It's a good idea to look what's the difference between the Telerik controls that work and those that not work (while they are in the same location on disc and in the same assemblies.xml).

Another question: in the $DLC\bin I also see a Progress.Telerik.dll.

Do you know what that is? Could some controls work because they are referenced in there?



Posted by Matt Gilarde on 30-Mar-2018 06:45

The Progress.Telerik.dll assembly implements the OERadForm class (the equivalent of Progress.Windows.Form for RadForm) and a set of related classes. It has references to Telerik.WinControls.dll, Telerik.WinControls.UI.dll, and TelerikCommon.dll.

Posted by Laura Stern on 02-Apr-2018 07:52

A similar issue has been logged with Tech Support.  We will try to resolve that one to learn what is going on.

Posted by DenDuze on 03-Apr-2018 01:09

@Matt: so that can be the reason why some Telerik controls just work and others (that have a seperate dll like GridView, ChartView, ...) not.

Posted by DenDuze on 03-Apr-2018 01:10

@Laura: Great, let's hope the reason is found quickly because I'm a bit stuck with this behaviour

Posted by mollyfed on 03-Apr-2018 01:44

Have to admit not reading everything 100% in this thread but wonder if your hitting this issue:


We have it a lot with our application but admittedly its not a Webclient application but unless Progress have added something to the WebClient distribution method, I don't see why you wouldn't possibly hit this issue! By the way, I don't think the Kbase mentions this but it can effect the assemblies file itself as well.



Posted by DenDuze on 03-Apr-2018 02:09

Yes that was it!! Thanks!

Why some of the Telerik dll's where marked as this and other not is a big question to me.

Also it's strange that when you copy that dll to $DLC/bin it worked - but OK it's solved now and that's great!

Is there some way to auto check all dll's in our propath on this setting and if set unblock those auto (because this is a problem that can return in the future I guess)



Posted by Laura Stern on 03-Apr-2018 07:58

Really?  Wow.  I am also very surprised that copying a blocked .dll will unblock it!  Admittedly, I haven't looked this up, but it wouldn't make sense to me to have a programmatic way to unblock a .dll.  That is something a user must do.

Posted by DenDuze on 03-Apr-2018 08:16

I never claimed that copyng a blocked dll unblocks it (didn't look @that). I only know that if I copy that blocked dll to the $DLC/bin it worked without a problem.

I found on the web a few ways how to unblock files with script/program.

Still need to look how I can use that to prevent this problem in the future.

Thanks for all the help

Posted by Jeffrey Z. Wolf on 05-Apr-2018 14:24

Hello Didier

I am looking into a similar issue. I found that fuslogvw.exe does not give a full picture of where .dll are being looked for. I found that the Windows Sysinternals tool entitled procmon gave a much fuller view of what files are being touched when in the process of binding assembiles. There is a lot more stuff to wade through, but at least with procmon the information is available.


Posted by DenDuze on 09-Apr-2018 01:13

Hi Jeffrey,

Thanks for this but I already used procmon to find the problem but also there I saw no reason for the problem.

Like said before the problem was the blocked-flag on the dll-file.

But still thanks for the tip!


This thread is closed