Webclient: application with Telerik controls => Could not

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.

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).

regards

Didier

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.

Regards,

Peter

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.

regards

Didier

Didier,

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.

Peter

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.

regards

Didier

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.  

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)

regards

Didier

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.

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?

Regards

Didier

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.

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

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

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

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

knowledgebase.progress.com/.../000051521

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.

HTH

Molly

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)

Thanks

Didier

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.

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

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.

Regards.

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!

Regards