We're using an MVC-based plugin architecture using ASPX pages (because Razor ones need to be precompilated). Thus we're using a custom AssemblyResourceProvider to get the custom streams for the pages.
The problem comes when we try to load a Silverlight Application on the ASPX page that's on the same assembly as the page, as an embedded resource (because we want a full plugin architecture, a single dll should be enough for everything). Even with using a physical .XAP we can't get it to work, we suppose that as the path of the page is virtual, it won't be able to search the file thus generating a 2104 silverlight error.
We can use a http uri to get the .xap, and it'll be out last resort, but we'd like to do something similar as creating a custom AssemblyResourceProvider for ASPX pages and getting the stream from the assembly.
Is that even possible?
Related
B"H
Trying to revamp my global error handling, and running into the mess that is ASP.net error handlers.
I would really like to consolidate my solution as much as possible. So if possible I'd like to use the same pages to display from httpErrors and customErrors. I'd also like to use the appropriate Layout pages if possible. But it seems that if I want to use some kind of dynamic page as a custom error page that it needs to be *.aspx. Why is that? Especially now that we have Razor Web Pages?
PS. This is for an MVC (.net v4.7 ie not asp core) Site
If you are using the .cshtml file as a Razor Web Page, then can't you give the URL of the file, excluding the .cshtml? As per the table here: https://learn.microsoft.com/en-us/aspnet/core/mvc/razor-pages/?tabs=visual-studio
A standalone .cshtml file is will normally depend on a Code behind file (if using Razor Web Pages) or a MVC Controller Action to provide it with its data. I guess this is why you are not allowed to redirect directly to one.
I am trying to use aspx pages as an email templates. There will likely be a bunch of objects on the page which will be used as replacements in the html. Because it's an aspx page I'll be able to use databinding, repeaters, etc. At run time, I want to be able to instantiate the aspx page from its path, pass in a bunch of properties, and then get the rendered result of the page and email it. This seems pretty straightforward from a asp.net website (maybe using BuildManager or Server.Execute.) However, I want to be able to use the same templates via a console application by just loading up a page object from its filepath. Is this possible?
You could host your own webserver. Like the Cassini webserver.
In my own application (a Windows-based Desktop-CMS), I include a web server, too (non-Cassini). It works very well, also it does not serve ASP.NET but plain, HTML.
As I did some research back then, I first wanted to use the Cassini, too, but at some point, I found out that too much user privileges were required to run it successfully; this may not be an issue to you, but keeping this in mind and try to run it early with the permissions of the later user, might be a good idea.
I'm building an HTML5 application (with ASP.NET back-end) and i want to develop it in such a way that i can run it locally with all my resources (such js and css) not minified (so i can debug it easily). However when i build the final version i want merge and minify the resources. At the same time i want to create several versions of the app targeting different platforms (iPhone, iPad, desktop, etc) by adding appropriate css.
I thought that the final output should be a set of html files (so the get cached nicely). I could use ASPX and just control the output by a query string parameter, but i don't really want to have the form tag on my page.
So the questions are:
What are the pros and cons of using static html pages generated from a template versus a dynamic ASPX page? (apart from being able to run on any web server)
If ASPX approach good enough then how can i get rid of the form tag that's required by ASP.NET?
UDPATE
Another factor in favor of static html pages is the fact that the files are served instantly, whereas ASPX may take awhile to load if the app has recycled.
The back-end is ASP.NET 2.0.
What are the pros and cons of using static html pages generated from a template versus a dynamic ASPX page? (apart from being able to run on any web server)
Pros:
Less overhead as you no longer have to serve ASP.NET pages through IIS
No viewstate, smaller page sizes (as long as your generator or build process removes them)
Faster loading times (due to the reasons above), though this could be achieved serving ASP.NET files with output caching.
Cons:
You obviously lose the ability to serve truly dynamic pages. This isn't a problem if you're not processing forms or have data that doesn't have to be updated often.
If ASPX approach good enough then how can i get rid of the form tag that's required by ASP.NET?
If you want to use WebForms and serve dynamic pages you can't get rid of it. If you're wondering how to get rid of it after the static html pages are generated, that could be done using an HTML parser simply enough during your build process.
I ended up using aspx pages. I removed form tag and it seemed to work (as long as i didn't use viewstate)
Around 90% of the pages for our websites have no .Net code embedded in them yet are published as .aspx files. I want these to render as fast as possible so I'm removing as much as I can.
Does the .Net page directive have an impact on performance? I am thinking about two factors; the page speed for each GET and what happens when the file changes. The CMS system re-creates each page daily and I'm wondering if this triggers the ASP.Net compilation process.
If your pages have no .NET code and rendering speed is your goal, you may wish to consider changing the extension to .html. Any .aspx page will be passed to the .NET ISAPI filter by IIS and go through the entire chain of HttpModules, then will be handled by the Page HttpHandler. Using a .html extension would trigger IIS to process the request using the Static Resource ISAPI filter, which has a much shorter pipeline and is tuned for resources that run no code.
The <%# Page %> directive is not required. Without it, the default values for Language and other stuff will be assumed.
By changing a .aspx file, it'll be recompiled (it doesn't recompile the whole app though):
Any changes to a dynamically compiled file will automatically invalidate the file's cached compiled assembly and trigger recompilation of all affected resources. The next time a request to the code is made, ASP.NET recognizes that the code has changed and recompiles the affected resources of the Web application. This system enables you to quickly develop applications with a minimum of compilation processing overhead. (Note that depending on the change to the resources, the result can range from recompiling a single page to recompiling the whole Web site.)
Ok, put them in - just to be sure.
.NET pages are ALL compiled, page directive or not. nothing changes. Post compilation, they are as fast as it goes, as they turn into a class (type loaded once) that just executes.
Note that the post by Mehrdad Afshari is factually wrong (sadly I can not tag it). Any page change triggers a complete recompile AND restart of the appdomain. Acutally any FILE change does so, as long as it is outside App_Data and ASP.NET can see it (i.e. non-hidden flag on the directory / file).
I have an aspx page that get copied in the layouts directory of a Project Server instalation. The aspx is a web part page that has a web part zone. How can I add a web part in the markup of the page, within the web part zone?
You can use the SPLimitedWebPart manager to add an instance of a web part at runtime. I do this on our MySites to control adding, deleting and moving web parts that the organization requires. You can put the code in the aspx page.
SPFile thePage = currentWeb.RootFolder.Files["default.aspx"]
using (Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager spLimitedWPManager = thePage.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared))
{
Assembly assembly = Assembly.Load("WebPartAssemblyName");
WebPart webPart = (WebPart)assembly.CreateInstance("WebPartClassName");
spLimitedWPManager.AddWebPart(webPart, ZoneId, ZoneIndex);
}
You may need to do something different to gain access to the Web Part Manager for your layouts page. After this you need to redirect back to the page to display the changes. You'll also want to store a bit value to ensure that you do not perform the action on each subsequent visit.
If you only need to do this once then I might recommend PowerShell instead.
Otherwise you can add the web part directly in MarkUp by registering the tag:
<%# Register TagPrefix="ABC" Namespace="Namespace" Assembly="Assembly" %>
and directly adding the web part,
<ABC:ClassName ID="ControlID" FrameType="None" runat="server" __WebPartId="YouWebPartGUID" WebPart="true" />
but we didn't do it inside of a web zone because we did not want to allow it to be removed so I do not know if it works in that scenario. This is easiest but doesn't allow for any customization and SharePoint doesn't really "know" about the web part.
You cannot have customizable Web Part pages in the layouts directory! This is only supported on Web Part pages stored in a document library or other folder in an SPWeb, i.e. ASPX files that you can get an SPFile reference to. Web Parts on ASPX pages in the layouts directory must be added as Web controls in the ASPX source.