MVC-3 Doesn't Find Pre-compiled Views - asp.net-mvc-3

I have a common MVC3 project which has some views which are compiled into the assembly using RazorGenerator. I've confirmed that the classes show up in the resulting DLL. I've referenced this project from another MVC3 project. When I try to use a view in the common MVC project (the view's namespace is CommonMvcProject.Views.Shared, for instance)...
#{Html.RenderPartial("ViewFromCommonMVCProject");}
...I get an error:
The partial view 'ViewFromCommonMVCProject' was not found or no view engine
supports the searched locations.
I don't want to use the physical views, I want to use the pre-compiled views in the common MVC project's assembly. How can I configure this project to search within the common assembly?

The following post looks like it has the details you need.
http://www.chrisvandesteeg.nl/2010/11/22/embedding-pre-compiled-razor-views-in-your-dll/
Hope that helps.

Related

How to use Localization in Shared Project? Xamarin.Forms

I want to make a multilanguage program via using resources(.resw files).
Its really easy for PCL but I dont know how to do it in Shared Project?
Create a Portable Class Library (PCL, or just Class Library Project) using .NET Standard, in order to localize resources in a Xamarin.Forms shared project.
Create the PCL, and then reference it from all 3 projects (Android, iOS, UWP).
Using a naming convention like AppResource.resx for the main resource, select that code generation should be Public, from inside the resource editor (in the top toolbar, there is a drop-down.)
Afterward, create a resource filed named AppResources.fr-FR.resx for French, for example. Always use the format ResourceFile.Language.resx.
Code generation will automatically be disabled for the localized resource when you name it, by the project manager. Keep it that way. It doesn't need code generation.
VoilĂ ! You can now access localized resources from a shared Xamarin.Forms app using a Portable Class Library.
Now you can follow the rest of This Tutorial From Microsoft from within the PCL.
I've faced some day ago the same problem (and with .net standard there isn't documentation about it).
I've created a library to do quickly the localization also in shared project.
Hope it helps:
https://github.com/andreabbondanza/DewXamarinLocalization

ASP.NET Core MVC controllers in separate assembly

I'm using ASP.NET MVC Core RC-2. I have a web project targeting the full .NET framework. I also have a separate class library in the solution, also targeting the full framework.
In the class library, I have a controller, marked with a route attribute. I have referenced the class library from the web project. This assembly references the nuget package Microsoft.AspNetCore.Mvc v. 1.0.0-rc2-final.
It was my understanding that this external controller would be discovered automatically, e.g.
http://www.strathweb.com/2015/04/asp-net-mvc-6-discovers-controllers/
However this doesn't work for me- I browse to the URL of the route and I get a blank page and it doesn't hit my controller breakpoint.
Any ideas how to get this working?
Interestingly, it does seem to work for web projects targeting .NET Core Framework, referencing a class library also targeting .NET Core. But not for a web project targeting the full framework, referencing a standard .NET class library.
Note: this is MVC Core which is supposed to support this kind of scenario without any MVC<=4 routing overrides.
Still an issue in ASP.Net Core 1.0, not sure if it's by design now. Easiest solution is to do this in Startup.cs/ConfigureServices
services.AddMvc()
.AddApplicationPart(typeof(<class in external assembly>).Assembly)
.AddControllersAsServices();
AddApplicationPart explicitly includes the assembly in searches for controllers.
The call to AddControllersAsServices() will add all the discovered controllers into the services collection, and if you put a breakpoint after this line and inspect 'services', you will see in the collection all the controller types which have been found.
You might also want to check here: https://docs.asp.net/en/latest/migration/rc1-to-rtm.html#asp-net-5-mvc-compile-views as the discovery rules are now changed for controllers from RC1.
Also remember to use IActionResult instead of ActionResult!
I believe you are hitting the following known issue in RC2.
https://github.com/aspnet/Mvc/issues/4674 (workaround is mentioned in the bug)
This has been fixed since then but will only be available in next release (unless you are ok with using nightly builds)

Referenced Library Not Recognized when compiled

I have created a simple Console application. I moved all my class files into a separate project because it is shared between this and a Asp.Net MVC application. I add the library fine. I add a reference to the project just fine. Everything looks good until it compiles, then it suddenly can't find the referenced namespace of the project. If I remove the using statement and add it back in the auto complete works fine and sees the project. It's only when building that it gives an error.
At first sight it looks like you're not doing anything wrong. In the past, I've had issues similar to this and the main causes were...
Both projects are targeting a different version of the .NET Framework. It can easily be changed from the project's Properties page
There are compilation errors on the referenced assembly (class library in this case)
The referenced assembly has some missing dependencies. It could be some like a reference to the System.Web assembly or System.Web.MVC, etc

MvvmCross with two core libraries

Is it possible to link two Core libraries into your app?
I would like to create one Common.Core library that has login and account view models.
I would like another one Domain.Core library that has some domain view models in it.
These could be used across a couple different projects.
In my app, I do a new Setup().Initialize().
My Setup class overrides CreateApp() ...
public class Setup : MvxPhoneSetup
{
protected override IMvxApplication CreateApp()
{
CreatableTypes().EndingWith("Service").AsInterfaces().RegisterAsLazySingleton();
return new Common.Core.App();
// TODO: can I setup a Domain.Core library here too?
}
}
I have tried doing this ...
CreatableTypes(Assembly.Load("Domain.Core")).EndingWith("Service").AsInterfaces().RegisterAsLazySingleton();
but I'm getting a ReflectionTypeLoadException when I try to resolve a domain model from there.
Anyone tried something like this?
Thanks!
Yes, using multiple 'core' projects should work.
The ReflectionTypeLoadException occurring on Resolve suggests that maybe your second Assembly requires another Assembly that isn't available? Do you get the same problem with a very simple second core project? Can you get any more information about the exception? Which platform is this occurring on?
If you want to load ViewModel types from multiple assemblies, then there is a Setup method you can override - The default ViewModelLocator in MvvmCross gets its list of ViewModels from the assemblies listed in Setup - see MvxSetup.cs
(Sorry this list is in the ui project - should really be in the main core project)
For cross-platform compatibility, I don't recommend using Assembly.Load - better to use a more static method like typeof(Domain.Core.Something).Assembly
Working on 'packaged application' platforms like xamarin.android and (especially) xamarin.ios I don't recommend using Assembly.Load - this will only work on the iOS platforms if the assembly is referenced statically and has already been loaded - that's the reason plugins have a special bootstrap file on iOS. Also be aware that the name used in Assembly.Load is different on different platforms - eg in Android you must use the filename ending in .dll - see MvxAndroidSetup.cs. For other platforms like WP and winRT, then Assembly.Load may work more conventionally though - although I've personally spent hours/days/weeks swearing at this sort of code in the last year.

ASP.NET MVC 3.0 - Why strong-typing Model in a View, if static compilation is not happening?

I'm actively developing desktop applications, local and network services, some classic ASP.NET, etc., so I'm used to static compilation and static code analysis. Now that I'm (finally) learning ASP.NET MVC 3.0 I'm seeing that many of the ASP.NET MVC experts and experienced developers are recommending using strongly-typed views in ASP.NET MVC 3.0 (where applicable).
I'm guessing that "strongly-typed" means writing #model=... at the top of a view's code. But in doing that I only get IntelliSense to work, no static code checking is taking place. I can write anything I want in the #model statement in cshtml and it would compile and run. Consequentially, Model.Anything also compiles. In fact, if I don't type #model I can dynamically use whatever model I want that has "compatible" properties and methods.
I'm used to "strongly-typed" meaning "won't compile", like LINQ to whatever just will not compile if you don't get the properties right. Is there any other purpose for #model other than IntelliSense and a run-time error, and why is it called strong-typed if it's in fact, not?
Strong typing, Meanings in computer literature
Views are compiled at runtime by default. You can modify your project file (csproj) to compile the views when the application builds by setting the following property:
<MvcBuildViews>true</MvcBuildViews>
Downside of this approach is that your buildtime will increase significantly. You should consider only setting this option to true for release builds.
You can edit your project file by unloading the project, right-click the project and choose Edit ProjectFile
It is possible to setup your project so that it includes views in your compilation. This would be where static typing is useful. Another place would be in runtime, if you try to pass in a model that does not match the expected model you will immediately get an exception. If you were to type views dynamically then you would not know your model was invalid until your view tried to access a property of the model and finds out it isn't there.
The second scenario is also a nightmare if you pass in the wrong model object but it happens to have the same named property as the expected model. Then you just get invalid data and debugging becomes hell.
model is new dynamic type in .net 4.0, so these types get resolved at runtime not at compilation time.

Resources