0

So the one thing I know is that with 4.5, iframes went from being HtmlGenericControls to HtmlIframes. This issue didn't start until I went from 4.0 to 4.8 but the iframe change does seem to be the driver of this issue.

The application I'm working with has 2 solutions that link differently depending on environment: a parent and a child when deployed to dev or prod (served via IIS, IIS 10 I guess based on the about menu) versus running side by side when testing locally (run via Visual Studio). To make the dev/prod instances work, I've had to delete the web.config in the child application's directory with each deployment and just let the web.config of the parent pass down. I have looked and both solutions' web.configs appear to be targeting 4.8:

<compilation debug="true" targetFramework="4.8">
...
<httpRuntime targetFramework="4.8" maxRequestLength="51200" enable="true" executionTimeout="1800" requestValidationMode="2.0" />

When I look at the built in error messages served both locally and in the servers, they do appear to match in looking for the same version:

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.8.4494.0

The frustrating thing with the project is when I work on it locally, it updates designer.cs towards HtmlIframe, but then I forget to manually go into the designer and change it to HtmlGenericControl, deploy to dev and as soon as it gets to the child application, I get the error message:

Parser Error Message: The base class includes the field 'FRAMEmain', but its type (System.Web.UI.HtmlControls.HtmlIframe) is not compatible with the type of control (System.Web.UI.HtmlControls.HtmlGenericControl).

And if I manually change it to HtmlGenericControl, and later attempt to test locally, I get the similar error message but the expectation vs reality are flipped:

Parser Error Message: The base class includes the field 'FRAMEmain', but its type (System.Web.UI.HtmlControls.HtmlGenericControl) is not compatible with the type of control (System.Web.UI.HtmlControls.HtmlIframe).

do the targetFrameworks in the web.config not do what I think they do? My goal is to make it so that dev/prod are looking for HtmlIframe like my local environment is so I can be rid of this, but they seem to treat it as 4.0. Initially, I thought the new servers that are running it didn't have anything but 4.8 installed as that was all that was in Windows/Microsoft.NET/Framework64, but then I looked in Framework and found that 1.0 to 4.0 have versions installed.

Edit: to throw more of a monkey wrench into this, I looked at the parent solution and it too has some iframe controls (sigh) in it yet it runs fine when HtmlIframe is in the designer file. It only seems to regress for the child solution.

Robert
  • 1,745
  • 5
  • 34
  • 61
  • Having just quick read of above? No matter what you do, having to drop into the designer is BEYOND a bad idea. In other words, you can mess with code file, and mess with the aspx page (the markup). However, ANY development approach which requires you to touch and mess with the designer files? Nope, you will wind up in a room with padded walls - don't do that!!! As for the web config and .net versions? Just make them all the same (4.8 or whatever), and you are done. The web configs (to my knowledge) don't change how or what the auto generated designer files do, and you simply never care. – Albert D. Kallal Jun 27 '23 at 14:31
  • agreed, I don't want to flip-flop HtmlIframe/HtmlGenericControl constantly between local runs and deployments which is why I ask. And I believe I have set them all to 4.8 but for some reason, the child application seems to still want HtmlGenericControl even though the error says it is ASP.NET Version:4.8.4494.0 – Robert Jun 28 '23 at 20:13
  • Ok, are you deploying as a asp.net web site "application", or that of a asp.net web site? As a web site, then IIS does the compile, and the "designer" files don't exist, and are not used. And yes, somewhere between .net 4 and 4.5 or whatever, yes, the designer does tag and generate a different control. My suggest then is to use what the later system does use, and if that breaks the compile/build, then you REALLY need to track down and fix that issue. So, I 100% agree that change came along un-expected, but it should not break your build, and fixing it for 4.8 should only have to occur one time – Albert D. Kallal Jun 28 '23 at 21:43
  • So, when you "publish" (I publish to a local folder), then all code pages should be removed, and all designers files should be gone. You only wind up with .dll's, and aspx pages. you have to post a simple markup page in which the build fails, since it not clear why the build fails, and what part of the application does not compile. My spider sense thinks that your deploying to IIS as a web site, but working on the project as a web site application. – Albert D. Kallal Jun 28 '23 at 21:45

0 Answers0