In ASP.NET Web Forms, I know when the C# changes the primary DLL also needs to be deployed. I also know when the markup (.aspx, .master) changes where new controls are added, the primary DLL needs to be deployed.
What about when the markup (.aspx, .master) changes and no controls are added? Can the .aspx or .master page be changed without deploying the associated DLL? I see 2 scenarios that may have different answers:
Simple markup changes (e.g. HTML, CSS. JS)
Dynamic changes in the markup (e.g. add <%=Page.ResolveUrl("~/test.aspx") %>)
**Note:
Ideally I'd deploy the whole app on any change, but I'm dealing with a fragile legacy app.
.aspx or .master pages be changed without deploying the associated DLL provided changed contents/controls don't change the interaction with the server-side code. For example in Home.aspx you add a paragraph <p>Sometext</p> deploy just Home.aspx, application would keep working.
On the other hand, obviously, if any control name is changed/event is added, you need to deploy associated DLL (after necessary updates).
I hope this helps!
Related
In my current ASP .Net Core 3.x project using Razor Pages there is a "Reports" page. Each report is a separate assembly on a server. When activated, the client downloads the report's markup (HTML + JS + CSS) through API and renders it dynamically on a page. This works perfectly and makes each report to have it's unique UI with specific validation rules, external requests, etc., since custom JS is used.
Now I'm planning to make a new project using Blazor with the same functionality but this time without JS. Only pure C#.
The only way to render this kind of dynamic content that I've found is through manual RenderTreeBuilder logic. But it seems to be very low-level for this task and that sign saying "These types should be considered unstable and subject to change in future releases" makes me a bit nervous.
So the idea is to dynamically download the entire assembly for the report (or a .zip containing multiple assemblies if needed) and render it's UI with all the logic behind it. It seems that assembly lazy loading could be used for this task, but I'm not entirely sure how to use it for dynamic assembly resolution.
The issue is that this feature requires static information for assemblies that are marked as "lazy" which is not available to me, since reports are separate "plugins" in a server folder. Also it seems that ASP .Net Core hosted solution is also required and my plan was to use static hosting.
In the end I wanted to have a static Blazor SPA, hosted behind any type of a web server (NGINX, Apache, etc.) which requests reports from a API server and renders their UI dynamically with all the logic written in C#.
Any ideas where to start? My thoughts are to go with lazy loading, but not sure how to use that feature for the task.
I was working with other Dev team (I'm mostly a winform Dev) and I saw the following:
Our APP is an ASP.NET App. This application(solution) has a webfrom project
and also several VB dlls(for business and data layers).
Recently one ASPX page changed(VB code behind),
And also a dll which this page was using.(VB dll data layer)
So solution was built successfully, without errors.
When they were deploying this change to the webserver they only copied the VB DLL for data layer and the webproject dll. So only 2 dll copied.
My question is why we didn't need to copy ASPX files to webserver?
This might help you to understand the issue.
Aspx pages converts to dlls.
http://forums.asp.net/t/1909746.aspx/1?File+updating+Issue+on+hosting+provider+server+
OK Here are results of my re-search so far which I hope the future viewer of this post finds usefull.
If you change a Webpage HTML part you Do need to copy the ASPX page to the server. In this case copying the web project DLL won't reflect HTML changes.
If you only change the code behind and "do not touch" the HTML then you can just copy the DLL to the sever. The Website clearly does not care about code behind VB or C# files.
Note that in my option the above case is highly a bad idea, as now we have a ASPX.VB or ASPX.CS file(s) sitting on the web server which have a different code with the dll. Therefore for consistency purposes all of these files should be copied together.
I have a user control (UserControl1.ascx) and I made changes to Its cs file.
That UserControl1.ascx is being used by two or more aspx files using LoadControl.
I don't want to deploy the whole web project dll as this is a fix for a critical issue in a part of the web app and doesn't affect the whole web app.
Updating changes to the single web form code behind is easily done. However not sure about the single user control deployment. Any help is appreciated.
it's a bit of a hack but you could move the code from the .ascx.cs file to the .ascx file and remove the inherits attribute. Asp.net first checks the referenced class in the inherit attribute. So I think this should allow you to update the web application without updating the .dll files. I didn't test this however, but I think it could be a viable option.
If you just deploy the updated user control (ascx) form and the relevant DLL, the only discernible delay will be the load time of the first hit after deployment, which you can do yourself with a browser refresh.
I've recently become the maintainer of an ASP.NET web project. In the course of deploying some changes, we noticed that at some point the way the project deploys has changed. The project is a web application project. Currently, when I "Publish" it to my local machine, I can open the various .aspx files and see some code--a little ASP, mostly JavaScript, but the majority of the code seems to be compiled into a .dll.
What we would like is to build and deploy this application so that there is no code in the .aspx files--this is how it used to work, before the previous dev stopped maintaining it. There should be no code in the .aspx files at all, just a reference to the compiled .dll files.
Does anyone know what I'm talking about and how to set it up?
EDIT If it helps, it looks like the older version of the app just had text in the .aspx files that said "This is a marker file generated by the precompilation tool, and should not be deleted!" That is what I'm going for.
If you want to do this for your Website just Pre-compile your project for deployment only. You can check out the exact steps in this MSDN article
This will move all the codebehind files into the .dll and create .aspx.compiled files as pointers to the compiled versions in the .dll. Sounds like thats what was being done before.
The code shouldn't be visible from the client's browser.
Any code that in a code-behind will get compiled to a .dll which the pages in the application would reference. The actual code-behind files shouldn't get published with the .aspx files.
.NET code within the .aspx files shouldn't be visible on the client-side because it has no use on the client-side. It should be executed on the server-side to render HTML output to the client. If the .NET code is visible on the client-side in this case, it means the server isn't executing it and the site is essentially broken.
JavaScript code, of course, needs to be visible on the client-side. There are ways to obfuscate it, but the browser needs to see it in order to execute it. So in this case that code should be developed with the full understanding that it is publicly visible and nothing proprietary or compromising should be included in it.
JavaScript code has to exist on the client side, so that has to be on the server. Inline ASP code? I'd look into rewriting that into .NET.
In order to achieve no code in the .aspx files you need to write all the code in the code behind. You use the asp.net events in the life cycle to perform the generation of client code. For example, dynamically generated HTML and javascript could be generated in the Page_Load and written out as a Response. Any asp.net that you may use needs to be dynamically generated in the code behind with everything else.
You will still push HTML and javascript to the client, but all the code will be in assemblies/dll's except the header info in the aspx pages. I have only done this in the context of a web service ( RESTful) where I pushed out XML to an iPhone for consumption. Doing it for a full website may prove to be quite cumbersome.
It doesn't make sense to do this if the concern is security. Moving the code to an assembly is not much more secure than the aspx page. If the concern is to remain concise, I suggest moving to ASP.NET MVC 3.
I have built a user control in a project that I want to re-use in a separate project. I had seen similar attempts successfully accomplished by adding a reference to the original project and then registering the control via:
<%# Register Assembly="AssemblyName" Namespace="AssemblyName.Namespace" TagPrefix="xxx" %>
I did something similar, compiling the original project and referencing it in the subsequent one . The control has an asp:Repeater control within it. I then registered my control as above and placed the control on my page like so (the control has a string property named prop):
<xxx:ControlName ID="ControlId" runat="server" prop="21" />
However when I launch the control in the subsequent project, I get a null reference exception and the application chokes. Am I doing this the wrong way? Is it mandatory that I have an .ascx file in the subsequent project?
Any and all help is appreciated.
Thanks,
pbr
Just as a follow up to this:
I did some further research and learned that the mark-up language (materials on the .ascx page) do not get compiled into the assembly. Therefore you must have the .ascx file within the project that calls it if there is any markup associated with the control.
In the properties dialogue I set up a post-build event that copies the .ascx file over to the subsequent project Controls file. I reference it as I would any normal User Control and everything works fine.
Hope this helps someone out there with a similar issue,
pbr