Originally, I added CSLA to our solution and it would get compiled and loaded with the rest of the projects. The LocalHost remoting web app worked fine when CSLA project was part of the solution.
Recently we removed CSLA project, wrapped up the install and installed it on our dev computers. The CSLA.dll exists in the BIN folder on the remoting web app, everything looks setup correctly. However I am still getting a FileNotFound error
"Could not load file or assembly 'Csla' or one of its dependencies. The system cannot find the file specified"
what am i setting up wrong with the pre-compiled CSLA assembly
ward0093
Sorry for suggesting the obvious, but is your reference in your winforms application still valid?
ya... all objects that are marked as RunLocal work or... i can shut down the Remoting Site (forcing ALL objects to run local) and it works fine
All projects (especially the Business Library) reference the same pre-compiled CSLA assembly. I even tried coping the CSLA assembly to the BIN directory (and restarting IIS) of the virtual directory and nothing... still get the same error!
Also: http://localhost/RemotingTunnel/RemotingPortal.rem?wsdl works and returns the entire list of for remoting (if that helps at all).
any help would be great... this one is killing me!
ward0093
Good Advise above
Well... I did copy CSLA.dll (and its supporting files) to the bin and that did not make a difference. However, I can not copy my business library because it is part of the solution but I can say that it is physically in the bin with a date change after I compile and run the application. NOTE: everything works great if CSLA is part of the solution, no problems.
How does the file permissions need to be setup in the VDir? I am on a domain and remoting through my localhost:80.
ward0093
I checked all the directory security... I allow Read, Write, Dir Browsing, everything (on both the VDir and the \bin); Security: I have Anonymous Access "IUSR_[COMPUTER NAME]" and "Allow IIS to control password" (on both VDir and \bin) as well as Integrated Windows Auth. is checked
This is getting really annoying... What am i missing? I can not test my solution without adding CSLA back into the solution.
ward0093
ward0093:
However, I can not copy my business library because it is part of the solution but I can say that it is physically in the bin with a date change after I compile and run the application.
Well this could very well be the problem. The business layer needs to be availabe to both client and server (although the message you're getting seems to suggest csla is missing).
Have you tried just copying everything from the bin\debug folder generated by your solution and seeing if that works?
Everything is there...
I do not understand this... Does the .NET Assemblies have to exist in the bin? There are NOT "Copy Local" yet (and are not there physically now). If not, why does everything else have to be in the bin and not just the GAC?
ward0093
P.S. Does it have something to do with the signing portion of our assemblies (both the pre-compiled and the compiled)?
Tried everything, cleaned the solution, recopied everything... nothing is working
here is my stack trace incase that helps
---- EXCEPTION STACK ----
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(String assemblyName, String typeName)
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at TestProgram.BizLib.DatabaseDetails.GetServerRoot() in D:\Development\BizLib\DatabaseDetails.vb:line 20
No, only your assemblies should be in the bin folder including csla.
It could have to do with signing; a signed assembly can ONLY load other signed assemblies. Unsigned assemblies may load signed ones though.
I am affraid I had to give up and add CSLA back into the solution... I just could not figure out why it would not load the CSLA (or one of its dependencies) from a precompiled state.... it was taking up too much of our time
Anyways.. with CSLA as part of the solution everything works fine. Maybe someone else will find the reason..
Thanks for you help... I do appreciate it!
ward0093
Have you locked the version numbers down on all your assemblies including CSLA? You can get problems such as this when one assembly is referencing one version of an external assembly and another a different one. If you don't explicitly lock down the version number you will get a slightly different one every time you recompile and it won't be obvious that it happened. If you end up with different assemblies referencing slightly different versions like this, even if no code has actually changed, you will end up with that type of error. So three of your DLLs are looking for CSLA version 2.1.4.3456 and one of them looking for 2.1.4.3478. Since CSLA is not in the GAC and you can only have one of the two (or more) in the Bin directory it will always complain that it can't find one. Bad stuff.
Or it could be something totally different, but it is something to look at...
Thanks,
Kevin
Copyright (c) Marimer LLC