I'm trying to get Intellisense working for razor views in a non-ASP.NET project and would like to understand the relationship between VisualStudio's Razor editor and BuildProviders.
For background, I'm writing a framework on top of Manos (mono web server) that uses Razor for its view engine. I've got that part working perfectly, but Intellisense in VS doesn't work giving a range of errors from unknown types to unregistered build providers, depending on where the output DLL's of the project are placed.
My project is a .NET Class Library, with .cshtml files (build action none). The base razor view class is defined in a separate assembly (outside the project) which could be registered in the GAC, but currently isn't.
I've already read these articles:
http://www.west-wind.com/weblog/posts/2011/Jan/12/IntelliSense-for-Razor-Hosting-in-nonWeb-Applications
Need razor view engine auto-complete to work in a class library?
http://blogs.msdn.com/b/webdevtools/archive/2011/01/20/how-to-get-razor-intellisense-for-model-in-a-class-library-project.aspx
.NET - Razor outside MVC application - Problems with removing #inherits and providing #model
Sounds like I need to write my own BuildProvider, but can't find any documentation explaining the relationship between a build provider and razor intellisense.
Razor intellisense is flaky at best currently. However, if you're using VS SP1, its slightly better. The web.config workaround (as pointed in your third link) works for me in a class library as long as the extension is cshtml (haven't tried vbhtml so can't say for sure).
Also take a look here: http://razorpad.codeplex.com/
Similar to LinqPad, this will allow you to test your razor code ahead of time.
The Razor editor is pretty heavily tied in to the ASP.Net runtime, in fact it actually runs ASP.Net in the background in order to collect the necessary run-time information.
My only suggestion for getting true-fidelity IntelliSense is a bit of a super-hack. Rather than a Class Library, you could make your application a Web Application Project. A WAP is actually just a class library which VS can host a website from. if you clean out ALL the extra stuff (Global.asax, web.config, etc.) you may get exactly what you're looking for. It's a workaround, and a bit of a stretch at that but give it a shot, it may just work :)
Related
After importing this existing (and functional) site into Visual studio (tried 2017 and 2019 both) running .Net 4.0 I am getting a plethora of not found errors.
Codebehind pages are not able to see elements on the existing page
Classes are declared to be duplicated or ambiguous
Function names (both standard like Page_Load and custom) are reported as already defined.
I am sure that all these items are related. Here are the steps I followed:
Created new Web Application from Visual Studio 2017 template
Copied solution and csproject files into existing website folder
Added files into the project
Re-added references to site
Set custom class .CS files to Compile
Removed "unnecessary" using statements (which were already declared in web.config)
Create a new ProfileCommon stub referencing ProfileBase
Beyond all this I have tried renaming a number of these functions and classes (using the rename) to create a new reference point.
Not sure what else I can do on this beyond major changes or a complete rewrite (100+ pages of code so far) by creating the new class files then copy/paste.
What other options are open to me?
Ok, this is is a migration project. Only you can "determine" if you want to convert from a web site to a web site application, and the time and efforts for such a migration project.
Now, having stated the above? No question, that I prefer hands down a web site applications. Simple things like have VS compile and build the application, ability to add assemblies (and not have the mess of .dll's HAVING to be in the bin folder to resolve references - yuk!).
And then simple things like the ability to multiple projects in one project are things I come to enjoy, and expect over the years when developing software.
About the "only" thing going for a web site? Your deployment is oh so easy, since you can open a web page, or code behind, hit save, and you are done!
but, this means both source code (code behind) has to be deployed to the web site. As noted, I prefer a build and compile process in VS. This does mean that to make a "minor" change, then you have to do a full re-deploy of the whole site.
However, these benefits I like and enjoy? it not all a given that converting an existing web site to a web site application is worth the efforts. Only you can make this decision. On the other hand, you would not be doing this work unless you KNOW what you doing, and thus can determine if these efforts are worth the time.
Such a conversion and refactoring process is somewhat beyond a simple post on SO.
However some steps and tips are outlined here:
https://devblogs.microsoft.com/dotnet/converting-a-web-site-project-to-a-web-application-project/
I would consider starting over, and try the steps in above.
There is a "convert" option outlined in above, and this can save enormous amounts of time. It has been some time since I have attempted such a conversion, and I not tested the "convert" option in vs2022, and hopefully it still exists.
However, another possible option? Keep the site as web site.
Hi I want to make project that contains one Razor Class Lybrary.I want to use them like dll or other (I still don't now) in another Blazor WASM project.The problem is how to run and preview this Razor Component in developing process before I put it in Blazor project.How I know it is impossible to make this or I make wrong.I read a lot of examples but they are all for the case when all Razor components leaves inside blazor project.
I think it is imposible with case that you want.
You need to create other project like "MyDllDebug" and reference real project. When you finish your testing - make your library and "Debug" don't build in the package.
I have an open source ASP.NET MVC application there is an add-in called T4MVC and I can see all the html, aspx, images, Controllers, views files are integrated, I wonder how it works.
If I create a file(aspx,html...) has it to be integrated manually to that template(T4MVC) or by default it get mixed? could someone please advise of how to get this(T4MVC) ans MVC do work together since I am new in ASP.net MVC.
T4MVC is a template that Visual Studio will compile and execute when you save the file in the editor (there are tools to automate this; search for AutoTT or Chirpy to check them out).
The template scans your project to find controllers, views, images, etc. and generates code that allows you to reference those items programatically elsewhere in your code. Whenever you add, remove or rename a resource (any of the items the template looks for) the template must be executed again to regenerate the code output.
The advantage of T4MVC (over the use of strings to reference things) is that you get compile-time checking, as well as intellisense and refactoring support.
I have several class files in App_Code in an ASP.net website running in Microsoft Visual Studio 2005 Professional.
In liu of using a full unit test suite I just want to somehow compile those project-wide classses into an .EXE so that I can nightly run unit tests on them.
I do know how to create a separate C# library project consisting of those files and how to include them into my website--but that is not desirable--I don't want to give up the ability to make on-the-fly code changes of those library classes when running the website in the debugger. As far as I know .Net debugger isn't powerful enough to modify code in included libraries with instant auto re-compilation on page re-load.
So, I want my cake and eat it, too:
Command-line unit testing of website class files in App_Code directory
Being able to modify those class files w/o stopping/re-starting the web debugger.
Is it possible to have both?
You should put the code in an altogether separate class library/assembly, then reference it from your web project and the command-line utility. As far as I know, it makes no difference where you modify your code, when stopped in the debugger. Never had problems myself.
Hope that helps.
Your project is under source control, right? Right? In that case, you can use your source control system to include a link to your asp.net project's app_code folder as part of a separate unit testing project. The exact linking mechanism varies by source control platform, but done right it means there's exactly one instance of your App_Code folder in source control that's visible from two different projects. This way, everything stays up to date.
This has the advantage of allowing you to keep easy, uncompiled code right there just like you always have, but still making the code available for testing.
I have a problem with Spark.
I have compiled assembly with views, located in bin subfolder of website, that i created like below
engine.BatchCompilation(targetFolder, Global.AllKnownDescriptors());
On start of my app, a try to load compiled views:
svf.Engine.LoadBatchCompilation(Assembly.LoadFrom(Path.Combine(basePath, "SharedViews.dll")));
When debugging, i can see that this was successfull.
But ViewEngine doesn't find that views. It even doesn'n look for them in CompiledViewHolder where they are located.
May that problem be caused ny wrong IViewFolder?
Or i should do something more to use compiled views?
Thanks
Not sure if this is helpful, but in the documentation there's the following paragraph:
There is no dynamic recompilation of classes that are loaded in this way and changes to the spark files will have no effect. However the files must be available on disk at runtime. Sorry about that - but the different frameworks still needs to test for the view files' existence to know what view descriptor it should instantiate.
Do you have the view files in your directory structure?
I found out the solution - I compiled views not on app startup, but using different tool. So changes made to engine (registration of entries etc.) during compilation were vain.
So now I compile view on app startup and everything ok.