I'm getting the following error on a simple "Hello World" SF WebForms project when I publish it to a web hosting service: 

Could not load file or assembly 'MicroFour StrataFrame Base, Version=1.6.0.0, Culture=neutral, PublicKeyToken=99fe9917f71608a7' or one of its dependencies.

The web page runs fine on my development machine.  If I build a similar simple app outside of SF using pure VS2008, it works fine on the web hosted site, so they apparently can successfully host .NET applications in general.  I see a similar post in the WebForms forum from a year ago but don't think the solution is relevant now.

http://forum.strataframe.net/Topic8736-10-1.aspx?Highlight=assembly+web

TIA,

Larry

That would be true since the Base assembly is not used in that project.

The error message is telling you that it cannot find the Base assembly when the application is started.  On your development machine this is in your GAC so it is probably pullin from there.  If you copy the Base assembly (along with the other required SF assemblies) to the Bin folder on the hosted machine, it should find the assemblies without issue.

I assumed building and publishing an application would have pulled needed assemblies together automatically.   It seemed odd for VS to require this to be done manually, with no warnings of missing components until you run the web app.  So I poked around a bit and found the "Copy Local" setting Project/Properties/References that seemed promising for automating the process.  But this no longer works on custom assemblies apparently to provide them with greater "scrutiny"...  Here is MS's explanation...

"If you deploy an application that contains a reference to a custom component that is registered in the GAC, the component will not be deployed with the application, regardless of the CopyLocal setting. In previous versions of Visual Studio, you could set the CopyLocal property on a reference to ensure that the assembly was deployed. Now, you must manually add the assembly to the \Bin folder. This puts all custom code under scrutiny, reducing the risk of publishing custom code with which you are not familiar."

So manually copying the dlls did the trick.  Thanks Trent.