|
Wordle 301 5/6
⬜⬜⬜🟩⬜
⬜⬜⬜⬜⬜
🟩⬜🟩⬜🟨 Coin toss twix this and next guess. Stupid coin.
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
|
Interesting talk
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Just a general question. Has anyone else here had to deal with updating applications that were originally designed for Internet Explorer?
The client I have been working for has a few hundred such apps, and want to migrate everything to MS Edge (chromium version) before IE goes out of support on June 15th.
Some of these are really old, and some use rather odd switches that don't exist in Edge (--no frame merging for example).
For a lot of these we will run in IE Mode on Edge, but even that will reach end of support in the future, and further work will be required.
Likewise they have several windows apps using the WebBrowser (IE) control that will also need updating to use the WebView2 (Edge chromium) control. But it has a different API and will require significant recoding. Plus the WebView2 control itself does not support IE mode, which could be another hurdle.
I welcome any advice on this. I have several ideas, but welcome hearing your own experience with this.
|
|
|
|
|
We had a few sites that we totally redid from scratch so they would support phones and tablets as well via Twitter bootstrap.
The bigger problem could be what is the source that generates the old HTML: code or some form of template file?
|
|
|
|
|
The majority of these are ASP. Net sites for web apps, and. Net WinForms for the desktop apps.
We are not looking to re-engineer these sites, just patch them enough so that they will run in Edge. Not much of a budget for much else unfortunately.
|
|
|
|
|
If you have thousands of ASP pages, some sort of automated conversion might be worth building.
It might even be possible to write a JavaScript helper utility that dumps rendered pages into CSS equivalent elements with style attributes (or even just for a few critical elements like TABLE where old HTML attributes need to be converted)
We have used forward generation at least twice to have old UI definitions generate the new UI definitions for 1500 pages.
|
|
|
|
|
A good idea. But the apps have been written over 20+ years, and use a variety of technologies, frameworks, libraries, etc. So there is no consistent set of "issues" and not likely to find a way to script out a solution.
For example, one of these apps was written on Visual InterDev with classic ASP. It's huge and no one wants to take on the immense task of migrating it to. Net. A fix for this will not aplly to any of these other apps.
I have not been a contractor here too long 3+ years), but from what I can tell their dev teams did not follow a consistent plan when developing their apps. So the range of technologies used is all over the map. Their flagship application is written on a Java platform/framework, but is very dependent on IE to work. I am glad that I don't have to deal with that directly, though I have been sharing my findings with them.
If it was just the HTML/JS that was the issue, this would be trivial to deal with. But there are some things that are either a) very IE specific, or b) not supported in modern browsers because they security issues. This is where I am focusing my efforts.
One thing that is helpful is that they have moved all their code repositories into Azure DevOps git. That does make it easy to search across all the repos for any specific bits of code (ex. use of file protocol to access local or network files). So once an issue is identified, I can at least search for which apps might have that same code issue.
|
|
|
|
|
Definitely search for uses of the IE window.showModalDialog, especially occurrences that utilize the returned result.
That one is very high risk to convert since it is a blocking call.
|
|
|
|
|
Andreas Mertens wrote: just patch them enough so that they will run in Edge. Not much of a budget for much else unfortunately
In which case you probably need to speak up now, as at the very least you probably need some sort of tests set up to verify the changes have not broken anything(perhaps using Cypress).
My experience is that these sorts of supposedly simple conversions end up taking much longer than the person who sold this(and who did not first ask the developers) anticipated.
Much better to speak up now and risk annoying the project manager than later try to explain why it's turned into a bit of a mess.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
You may think I'm a band-waggoner, when I mention how you may be able to most easily solve this so hopefully you'll hear me out.
I'll attempt to explain this in the most terse way while hopefully convincing you that this thing I mention can actually help you. The reason I'm not mentioning it right away is because the technology is so extremely pushed that it has become a buzz-word (knee-jerk library).
(far too much) Background
I'm a long-time Software Developer & I take projects from nothing to completed so I'm always looking for anything to speed up development time.
I originally started out as a Windows Forms dev (under Win 3.1 -- yes, I've dated myself now).
However, I've always been open to technology so I try a lot of stuff. Sometimes those technologies are just buzz words.
Ok, here goes...
I like ReactJS for building Front-ends that work cross-browser / cross-platform.
Reasons I Like ReactJS & How I Believe it Can Help You
Main Reason I recently learned it is entirely possible to add ReactJS (get the benefits of the library) to a brownfield project. You can add small bits of ReactJS (components) to your current project & slowly realize all the benefits.
This is not much talked about because normally the ReactJS Tutorials simply say, "run npm install and install all of this toolchain". And then I'm turned off because it installs Babel & tons of other stuff I didn't even know about.
However, I started reading this book React: Up & Running: Building Web Applications 2nd Edition (amazon)[^] and it shows you how to start incorporating ReactJS into your existing project and getting benefits.
Major Benefit2
ReactJS wraps everything up so that it will run in older browser versions, including IE!
1. That means you won't have to worry about a bunch of odd syntax & searching for IE-specific solutions.
2. You can convert small chunks of a single web page into React so you can slowly convert a bigger thing (instead of biting off such a huge piece that you choke).
Quick Example (hopefully)
Here's a jsfiddle to a very simple example of creating a component that represents an HTML div.
Edit fiddle - JSFiddle - Code Playground[^]
And, it shows you how you can easily update the value in the div (text displayed).
The point here is that you can incorporate ReactJS from a couple of links (not have to install npm etc.)
<script crossorigin src="https://unpkg.com/react@17/umd/react.development.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"></script>
I learned so much from just reading the first two chapters of the book above.
You may think you have a learn a lot but it'll probably end up being faster than searching for all the cryptic IE code & converting.
Final Point
The final point is that everything will be wrapped up in components that you can easily convert small bits at a time & they will work even in old versions of IE.
Good luck.
|
|
|
|
|
I have alot of experience as well as a Windows developer - back to the Win 2.11 days, and been developing web apps since the 90s. So I am quite familiar with the various web development frameworks and technologies.
The issue isn't about the HTML/JS code itself, and the client doesn't have the budget to do that with the 100+ apps that are affected by this. Even if there was, there isn't enough time to address this by June 15th. Being a major gov't agency, they have a huge mandate to get off IE at that time.
The real issue is more about the differences between IE and Edge, and finding a way to patch these apps just enough to have them work correctly on Edge. Visual elements aren't as big an issue, and can be addressed by running them in IE mode. But several apps have very specific requirements tied to IE functionality, and trying to convert those are the real challenge.
I am really looking for suggestions on how others have dealt with such conversions. If it was just a matter of redesigning the app from scratch, I could do that easily enough myself.
|
|
|
|
|
Andreas Mertens wrote: The issue isn't about the HTML/JS code itself, and the client doesn't have the budget to do that with the 100+ apps that are affected by this. Even if there was, there isn't enough time to address this by June 15th. Being a major gov't agency, they have a huge mandate to get off IE at that time.
They actually do have the budget. They just don't want to pay out.
Further, if it needed to be done by June 15 for 100+ apps, they should have started writing taskers for it LAST JUNE (it's not like nobody was aware that IE was going away). I suspect you're not the person that wrote these apps to be IE-specific, but you can't really blame the original devs for that, because the DoD only supported IE for the longest time, and devs were probably relieved that they didn't have to code for 1,001 different rendering engines (we all know how splintered the various target browsers are, but modern innovations have resolved some of that where styles are concerned).
BTW, I seem to remember reading somewhere that "IE mode" has been removed from Edge/Chromium, so the only way to get "IE Mode" is with a group policy. If your comm squadron is anything like the one I have to deal with, good luck getting that turned on. Even if you manage to convince them to allow it, it uses the IE assemblies.
Do any of your apps use ActiveXcrement? If so, that's going to be a major pain point for you.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Actually, Edge still has IE Mode. It will supposedly be supported until 2027. But again this is a gov't agency and in some respects more reactive than proactive. I am doing what I can to change some of that but there is a lot of inertia. My goal for now is just to make sure everything is still capable of running on June 15th. After that I'll work on plans to remove all the remaining dependencies so that IE Mode won't be required, when there is a bit more time to deal with it.
I am well aware of what should have been done, planning and budget - wise. The situation is simply what it is, and they are well aware of it. Now they just need to get this fixed.
|
|
|
|
|
I'm sure he doesn't want to have to completely (or even just partially) refactor every app, and only wants to do what is necessary to make the apps Edge/Chromium-compatible.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I have just one web app (inherited) that only works in IE. We're forcing it to run in IE Mode in Edge. That will work for us as this application only has to live another year... at which time it will be replaced as part of a much larger application shift.
|
|
|
|
|
Yes, at least with IE mode we can buy more time for these apps as well. I should check with the various business managers on when they foresee the apps that need IE mode will expire in the short/medium term. Thanks for that suggestion.
|
|
|
|
|
Andreas Mertens wrote: I should check with the various business managers on when they foresee the apps that need IE mode will expire
Do NOT tell them that sunset is 2027, kick them in the pocket, they have already screwed up once.
Reminds me of the Y2K debacle.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
certain budget has to be allocated to modernize those app in a phased manner it all depends on you explaining to the client that these need to be switched out
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Andreas Mertens wrote: The client I have been working for has a few hundred such apps, and want to migrate everything to MS Edge (chromium version) before IE goes out of support on June 15th.
IE's been on its deathbed for years now, and MS hasn't been shying away from telling everyone. It's only now becoming an emergency?
I don't know anything about this situation, but why do I a feeling that developers are at risk of getting sacked for this? And this is not where to lay the blame.
I do realize it takes time for these things to happen, and they have to be budgeted accordingly. That is precisely my point.
|
|
|
|
|
My advice is to prioritize the apps in order of importance, and work them one at a time. As you progress from one app to another, you'll probably be able to use the code from the converted apps as a guide as to what to look for in subsequent apps.
BTW, there's this - "noframemerging" in Edge is not supported - Page 3 - Microsoft Tech Community[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 16-Apr-22 8:46am.
|
|
|
|
|
Actually, the first task is to determine which of these apps run "differently" on Edge vs. IE. Then to review these differences to determine which are critical and which are just cosmetic. This was already done.
We are just now evaluating which of these critically affected apps will work under IE Mode, and will use that for now - hopefully a temporary reprieve. I have the fun task of working on those handful of apps that are not working in IE Mode. Fortunately I do not have to deal some of the apps in other departments, but it seems I have the most experience with this and everyone else is looking to me to figure out these issues so that they can be applied elsewhere.
I know all about the fact that - - noframemerging is not supported. It's purpose in this case is to keep the data in a session totally separate from any other (as they run multiple instances of this specific web app) . I found I can simulate that by using multiple profiles in Edge, but have yet to find a way to clean these profiles up after use.
|
|
|
|
|
I would imagine there are libraries of polyfills that you may be able to drop into the headers of each page in your IE focused apps that would enable them to run smoothly on Edge.
My advice: don’t overengineer the solution here. Sure you could rewrite the whole thing, which would cost a bundle and result in apps that work probably pretty much the same, give or take some UI niceties. Is it worth it to the business to spend that much money? Will it result in more sales or whatever metric keeps your org alive?
Me: I’d just run them, one by one, in Edge and Chrome (there should be very little difference). Make notes of what’s busted, workout what needs to be fixed and what can just be cut out, then see whether you can find a library that will Help fill the gaps or whether you need to make the changes yourself. At that point you decide if it’s worth it for any given change.
If you rely on silverlight, activeX or browser helper objects then that’s a rewrite of those bits.
Unless you’re getting paid by the hour I’d resist the temptation to rewrite the whole thing. In 5 years time you’ll be back at this same place anyway, probably.
cheers
Chris Maunder
|
|
|
|
|
must probably it will have a lot of errors that will require a lot of time to investigate. To debug and update legacy code takes a lot of time, sometimes ever more than recoding from scratch.
|
|
|
|
|
Good morning to all of you that replied to this.
I appreciate all that you have responded with here. But quite frankly I am well aware of planning, budgets, testing etc. If I had been in charge of this, I would have started working in all this two or more years ago. But what is, is.
Nor do I need suggestions on updating the HTML or JS or frameworks, etc. All of that is pretty straightforward.
What I was looking for was any information from those people who have dealt with those truly IE specific technology issues when moving to a modern browser like Edge-chromium.
Things like, has anyone else had to deal with the - - noframemerging issue and what you did to overcome this. Or replacing the IE specific WebBrowser control in a WinForms app with the WebView2 control, especially when the WebView2 control does not support IE Mode.
Maybe this is too technical for the Lounge. In that case contact me directly. I can get all of these together and put out an article here for anyone else dealing with this (giving credit where credit is due).
Thanks again...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
