I'm experimenting with creating a plugin framework for ASP.NET MVC. I've managed to inject the controllers dynamically, but I've hit the wall when loading the view templates.
I've debugged MVC and located the problem to the following call:
BuildManager.GetObjectFactory("~/Views/HelloWorld/Index.cshtml")
The problem isn't that the path does not exist, but that it does not compile. The view is typed to use HelloWorldPlugin.Models.Message as a model, but it seems the BuildManager can't find the type. I had a look in Temporary ASP.NET Files and as expected, HelloWorldPlugin.dll does not exist there.
What stumps me is that before the application starts, I make a call to BuildManager.AddReferencedAssembly, passing the HelloWorldPlugin assembly as the parameter. This works fine for making MVC find the controller, but why isn't the BuildManager installing it to Temporary ASP.NET Files, and why can't it find it when compiling the view?
Your plugin assembly won't get copied to Temporary ASP.NET Files. Assemblies are loaded from the bin folder. BuildManager.AddReferencedAssembly is merely adding an assembly reference to the one that should be loaded in memory. It's equivalent to adding the assembly to the application-level Web.config file.
Can you share the exact error message you're getting. Did you check your bin folder to make sure that your plugin assembly is referenced properly?
Related
I have added a resource file in App_GlobalResources called FileList.resx.
Now I access the contents within the code by using
My.Resources.FileList.astro1 etc.
It works fine if I set the Build Action of resource file to Embedded. However in this case the resource file is not available after compile and I can't change it later.
If I set the Build Action to Content I get an error : Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "WAP.FileList.resources" was correctly embedded or linked into assembly "WAP" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Please advice me.
Are you using a Visual Studio Web Application? Or a Web Site?
In the latter case, you should be able to change the Resource file after deploying the site, and it should get automatically recompiled on the server. In the former case, it's a built-in that can't be changed after the site is compiled before deployment.
If that's a problem for you, there are of course alternatives to Resource files....
In any way of compiling and deploying your application all resource files will compiled in related to each resource file assemblies. In all cases, resource assemblies are ultimately created for each directory in the site, and satellite assemblies are generated beneath their respective culture-specific directories. Even when the site is JIT-compiled, the outcome is equivalent.
So, you must use Build Action of resource file to Embedded, but as possible solution for dynamic resource definition you can place you resources in a database. And even provide a Resource provider. In that case your database solution would have all the benefits that suggested by resource management aka dynamic culture definition, using resource binding to control, etc.
Here you can find some tutorials how to implement Resource-Provider Model in your application:
Extending the ASP.NET 2.0 Resource-Provider Model
Creating a Data Driven ASP.NET Localization
Resource Provider and Editor
I have encountered a very strange issue with localization in ASP.NET MVC. Let me outline my projects since it is not that straight forward.
I have a TRUNK version of my website. The website uses two localization techniques. The first one is to load resources within the views from App_LocalResources. The second technique is to load resources from embedded resources in DLLs (project references).
On one view I show some lables which are localized from the view and I also load some labels via AJAX/JSON. The Action gets the localized data from an embedded resource in a referenced class project (DLL). Actually, in TRUNK, this works pretty well.
Now the Problem: I have a BRANCH which does not have a project reference to the embedded resource but a reference to a compiled DLL (copy). In the BRANCH the localization only works for the View, not for the AJAX/JSON call which simply returns the default locale.
What can be wrong? Do you have to make an settings on the DLLs if you redistribute them?!
The message sent to browser is as follows:
The type My.API.Class is ambiguous: it could come from assembly '[on Temporary ASP.NET Files]' or from assembly '[on bin folder]'
The problem occurs when debugging a Web App, specifically when making a request to a WebMethod of a WebService.
The project compiles just right. It generates My.Website.dll on bin folder and if I publish the Web Application. It works fine.
The asmx file is on the root of the application. The CodeBehind file is on App_Code and its marked to be compiled to generate My.Website.dll.
I should be missing something really important.
I found someone having the same issue with a possible related cause. Check it out. The way this person exposes its problem is somehow similar but I get starting to be lost when he talks about a proxy class and shared dlls I don't use.
Any help is appreciated.
According to this, the App_Code folder should be used only on Web Site projects. That's the reason the CodeBehind of the asmx was compiled at runtime too.
The initial question was made based on a Web App. But I didn't specify this Web App. was been manually changed from a Web Site project.
To solve my problem I did the following:
Convert the project to Web Application. This will make App_Code to be renamed to Old_App_Code.
Moved all the Old_App_Code resources to a Class Library and then referenced this library into the Web Application.
#Tony: Thank you for guiding me.
The best way to debug issues like this is to use the "Modules" window in the Debug->windows menu of Visual Studio. It will show you all loaded assemblies. In particular, you want to look for My.API.Class in the modules list more than once. Sort the list by order loaded, and look at the dll right before it (that's usually the one responsible for the assembly to be loaded). The most likely cause of this is that one of your references also references My.API assembly, but references a different version of the assembly than your site does.
You can also fix it by adding your assembly name at the end of the attribute "Class" ex :
Instead of
<%# WebService Language="C#" CodeBehind="~/App_Code/WebService.cs" Class="WebService" %>
Use
<%# WebService Language="C#" Class="WebService, YourProjectName" %>
When you're making a web site, the assembly name is something random starting with "App_Code" but when you change it to a Web App the assembly name will be "YourProjectName".
This problem is only on development environment, so I guess my solution is better because you won't have to rename your folder (thie could cause problem with your source control).
I am relatively new to ASP.NET programming (but not programming in general), and I have been looking through a project that has been handed off to me. Within this project, there is a bin directory which contains a slew of various DLL files.
Then, in the web.conf file, inside the assemblies structure (within the XML), there is a slew of other assemblies being added.
I've done a search on both SO and through Google in general, and I am still struggling over what the difference is between the two. Is one way "better" than the other? Any clarification that can be provided would be most appreciated.
Thanks.
There are several ways to reference assemblies (DLLs, usually) in an ASP.NET application:
Add the DLL to your application's "bin" directory. This creates an implicit reference in every code file and ASPX file in your application to that DLL. This means that code inside an ASPX file or inside a CS file in App_Code can use the types in that DLL.
Add a reference to the DLL in the <assemblies> section in web.config. See MSDN for details on the syntax. There are generally multiple web.config files that apply to a particular web application. The application itself can have several web.config files (for example, a web.config in a particular folder might add its own references). There is also a global web.config (or machine.config) that has references available to all ASP.NET applications on the computer.
Use the <%# Assembly Name="" %> directive in a particular ASPX (or ASCX or MASTER) file. See MSDN for details on the syntax.
The references in a given file in an ASP.NET application is a combination of the applicable items above.
The reason you have to reference assemblies is that ASPX files (much like CS and VB files themselves) eventually get compiled by either the C# or VB compiler. In order for those compilers to know what types you want to use they need to know which assemblies contain those types.
The bin directory is a copy of all the dll's that are built and referenced by your project. When the web application is running, it looks in the bin directory for the physical dll's it needs to execute the web application.
I have a web app that I wanted copy to a new project.
I created the new app with VS2003 and copied across the web forms, config, global asa, etc. and made sure IIS says it is a web app.
However, I still get this error when I run the app using IE from VS IDE:
ASP.NET v1.1 Could not load type TBRWEB.frmLogin
I also made sure the assembly name and root namespace are the same as original.
Any ideas?
These error normally occurs if the .aspx page or the Global.asax page contains a reference to a code-behind module and if the application has not been built.
Look in your project settings and check the value of the default namespace (in the application section).
Then check the "inherits" attribute in the control header of your ascx control (and yll other aspx/ascx files). I suspect that these two names are not the same. Creating a new project maybe you choose a different name which became the default namespace.
The simplest solution would be to change the namespace of your project to TBRWEB, if that is an option.
if it is not that easy, then my follow-up questions are:
Did you successfully build (compile) the application?
If it's a ASP.NET web site (not web project), did you forget to copy the .cs/.vb files in the App_Code folder?