IIS Linux possibilities for legacy application?
October 30, 2020 9:11 PM Subscribe
I have an application with "targetFramework=4.8" in the web.config. It is meant to be run under IIS10/Windows LTSC 2019. It is the only application we do not have the source code to and that runs under Windows, making our software development and deployment bifurcated. Can we run it under Kestrel/Mono or some other scheme that gets it under Linux? There might be support within the application for legacy .NET things but we're okay with some things no functioning. Spinning up an entire Windows Vagrant image on OS X is killing us.
The vendor provides us with a giant "Web Deploy" compressed file of the "c:\inetpub\wwroot" folder. There's a ton of things it appears to do that we don't need, like WebDav support. No one cares if we get a hard error trying to use that functionality, we've pretty well isolated everything important in the application. For reasons beyond this question, legally we have to use this application, but can pretty much do everything including decompilation. The vendor who provided this also has some sort of licensing check in here that is obfuscated and encrypted in one licensing DLL so I don't think it'll be possible to take the application and straight disassemble it without doing a lot of work.
In general, is there a path to move this to something like Kestrel that's multi-platform? We can't be the only organization that has this sort of problem. Is there something stupid about this question? it seems like if .NET Core supports earlier versions of .NET that this would be possible but Microsoft's marketing lingo is making this hard to figure out.
The vendor provides us with a giant "Web Deploy" compressed file of the "c:\inetpub\wwroot" folder. There's a ton of things it appears to do that we don't need, like WebDav support. No one cares if we get a hard error trying to use that functionality, we've pretty well isolated everything important in the application. For reasons beyond this question, legally we have to use this application, but can pretty much do everything including decompilation. The vendor who provided this also has some sort of licensing check in here that is obfuscated and encrypted in one licensing DLL so I don't think it'll be possible to take the application and straight disassemble it without doing a lot of work.
In general, is there a path to move this to something like Kestrel that's multi-platform? We can't be the only organization that has this sort of problem. Is there something stupid about this question? it seems like if .NET Core supports earlier versions of .NET that this would be possible but Microsoft's marketing lingo is making this hard to figure out.
Response by poster: Ah! Looks like it all worked except for configBuilders and some digging shows that this is an open issue. Sweet got close!
posted by geoff. at 10:39 PM on October 30, 2020
posted by geoff. at 10:39 PM on October 30, 2020
Response by poster: Look like Mono .NET is abandoned and there's nothing beyond 4.7.0. Anything new is at least two years old.
really poorly written python code using hardcoded windows style path separators everywhere that had to be hunted down and fixed, but we owned the source code, not the vendor, and there was still a live dev team working on the application.
Yeah that's what I'm afraid of even if I had it.
What's pissing me off is that apparently whomever was here before me chose to keep the application going due to a vendor promise they'd be on .NET Core ... five years ago. While technically you can build .NET Core applications inside the app that's a bit of a stretch to say it is .NET Core when you still require .NET 4.8 to run the project.
posted by geoff. at 10:57 PM on October 30, 2020
really poorly written python code using hardcoded windows style path separators everywhere that had to be hunted down and fixed, but we owned the source code, not the vendor, and there was still a live dev team working on the application.
Yeah that's what I'm afraid of even if I had it.
What's pissing me off is that apparently whomever was here before me chose to keep the application going due to a vendor promise they'd be on .NET Core ... five years ago. While technically you can build .NET Core applications inside the app that's a bit of a stretch to say it is .NET Core when you still require .NET 4.8 to run the project.
posted by geoff. at 10:57 PM on October 30, 2020
As somebody who works in enterprise software support:
Maybe, if you don't give a fig about getting any sort of support for it.
In your shoes I would be totally game to try, and I'd bet the licensing check isn't that obfuscated. But you're not getting the time of day from support if it breaks.
posted by wotsac at 8:06 AM on October 31, 2020 [1 favorite]
Maybe, if you don't give a fig about getting any sort of support for it.
In your shoes I would be totally game to try, and I'd bet the licensing check isn't that obfuscated. But you're not getting the time of day from support if it breaks.
posted by wotsac at 8:06 AM on October 31, 2020 [1 favorite]
Response by poster: Maybe, if you don't give a fig about getting any sort of support for it.
This is close to twenty year old software that's been worked on by multiple contractors over that time period. Support is something that only exists on paper at this point.
posted by geoff. at 9:24 AM on October 31, 2020
This is close to twenty year old software that's been worked on by multiple contractors over that time period. Support is something that only exists on paper at this point.
posted by geoff. at 9:24 AM on October 31, 2020
I agree that your best bet is to get this running under .Net Core. Unfortunately, .Net and .Net Core are not as close as the names imply. There are some API differences, so there's definitely a compile step in there, after you've decompiled. Depending on what the app does, it's maybe not a lot of work.
The licensing check presents a bit of a dilemma. If it's native code, it may be legitimately impossible to include in a Linux version. But now you've circumvented the licensing check, which is not something i would do without talking to a lawyer.
posted by Horselover Fat at 11:36 AM on October 31, 2020 [2 favorites]
The licensing check presents a bit of a dilemma. If it's native code, it may be legitimately impossible to include in a Linux version. But now you've circumvented the licensing check, which is not something i would do without talking to a lawyer.
posted by Horselover Fat at 11:36 AM on October 31, 2020 [2 favorites]
Response by poster: Yes I'm finding that .NET and .NET Core are similar in name only in every piece. Would be a lot simpler if this weren't full of marketing on all sides trying to push that this is a natural evolution. I guess to enterprise customers they don't want to hear of a breaking change or lack of support. That seems to scare them to death and we're left in a lurch, at least Microsoft broke away and my vendor I'm using did not.
In any case let me change my question. Running the vendor app in a VM is going to be heavy and outside our life cycle. Ignoring that getting something on Azure right now is a huge challenge because "Infrastructure Management Team" isn't structured to work in a modern development way. Like say we throw the app on Azure for each developer. They make changes to the app and they essentially want to do a "git reset/clean" sort of operation where they want to go back to their commit and revert the application. I'm sure there's ways to script Azure to do this, but is there a guide on how to do this or has anyone done something similar? What's the ideal workflow for this, I'm looking at the process as much as the tooling. Right now if I do docker-compose up or docker-compose down the other services all come down and up in a blank slate and I want to somehow have the legacy app do that and tied to a commit.
Giving the developers access to do this directly is not an option so normally I'd say make the developers admin of an account that can't touch anything else and let them figure out a development flow that works best for them, keep an eye on costs but otherwise don't really care. Bonus points if Azure has an "Enterprise Developer's Center" or something like that is essentially Azure wrapped in the word Enterprise and Developer that offers the same thing without the heart attack inducing, "give developers access to everything."
Right now this is pretty similar to how developers are working except the workflow looks like this:
1. Developer onboarded. Legacy application is setup in Azure per developer or sometimes worse in a shared developer database type environment.
2. Developers do their work but are afraid to make changes to legacy applications, are unsure if their changes will impact the legacy applications and often the legacy application isn't refreshed or reflective of what's on production meaning they can't test their code.
3. Developers have come to understandably hate the application and despite all the fanfare about change control and the like no one really knows if another developer had a request that changes a field name or table name, have no way of propagating those changes among developers and worse don't even know what to look for.
4. Often developers don't even try to think about how their changes can break because it breaks so differently on their machines versus test versus production they find a little corner to do their changes push it up and hope that one instance works. The organization is setup so that while it might be reasonably to say check if login works on mobile and desktop, if the request wasn't incredibly specific it is better to submit it working on desktop, not check it on mobile, and wait for the breaking ticket. For a lot of reasons checking it on mobile vs not desktop (bad example) will actually have people asking why it isn't done. This isn't explicit of course but the feedback loop it creates of not thinking outside the ticket means releases are on the scale of months, the releases are seen as stable only because they're incredibly atomic and narrow and developer turnover is high.
But we have some developers that really want change and unfortunately this mainframe style application is the last one in the organization we can't get rid of. All the Java applications have forced their way through a now approved and sanctioned backdoor of Docker. This was only because they were able to run their entire CI/CD process locally, then give it to the infrastructure team to run their CI/CD process. They were getting giant amount of features done without fretting about a system they had no control over. And they were getting those features done without bugs.
There's a lot to unpack here and a lot of it is not technical in nature but the management structure doesn't see themselves as needing a new way of overall approaching software development but finding yet another tool to speed things up. They can't change the legacy program but they can change from Javscript to Typescript, see an article about how Typescript improves productivity and then mandate everyone uses that.
I have a lot of sway but I cannot change their legacy app or their way of thinking without doing what the Java team did and prove the new method works.
Again this is an organization that plans for deployments by having everyone up to 2AM as the 200+ production servers are manually updated. This is not even the fake fun of the late 90s lets have pizza and beer while pulling an all-nighter, this is a bunch of people in suits sitting in a hot conference room. I'm in the odd position of having to change this little by little and hopefully getting some early victories so that I can go to upper management.
The real problem is the board is old and the average age is around 75 without exaggeration. Legal has a huge influence which is also about the same age and bills a lot of hours to deny things like React because React hasn't passed some sort of data security thing. There's never really a straight answer but they have no real incentive to give an okay on something. But this is way off topic.
posted by geoff. at 1:49 PM on October 31, 2020
In any case let me change my question. Running the vendor app in a VM is going to be heavy and outside our life cycle. Ignoring that getting something on Azure right now is a huge challenge because "Infrastructure Management Team" isn't structured to work in a modern development way. Like say we throw the app on Azure for each developer. They make changes to the app and they essentially want to do a "git reset/clean" sort of operation where they want to go back to their commit and revert the application. I'm sure there's ways to script Azure to do this, but is there a guide on how to do this or has anyone done something similar? What's the ideal workflow for this, I'm looking at the process as much as the tooling. Right now if I do docker-compose up or docker-compose down the other services all come down and up in a blank slate and I want to somehow have the legacy app do that and tied to a commit.
Giving the developers access to do this directly is not an option so normally I'd say make the developers admin of an account that can't touch anything else and let them figure out a development flow that works best for them, keep an eye on costs but otherwise don't really care. Bonus points if Azure has an "Enterprise Developer's Center" or something like that is essentially Azure wrapped in the word Enterprise and Developer that offers the same thing without the heart attack inducing, "give developers access to everything."
Right now this is pretty similar to how developers are working except the workflow looks like this:
1. Developer onboarded. Legacy application is setup in Azure per developer or sometimes worse in a shared developer database type environment.
2. Developers do their work but are afraid to make changes to legacy applications, are unsure if their changes will impact the legacy applications and often the legacy application isn't refreshed or reflective of what's on production meaning they can't test their code.
3. Developers have come to understandably hate the application and despite all the fanfare about change control and the like no one really knows if another developer had a request that changes a field name or table name, have no way of propagating those changes among developers and worse don't even know what to look for.
4. Often developers don't even try to think about how their changes can break because it breaks so differently on their machines versus test versus production they find a little corner to do their changes push it up and hope that one instance works. The organization is setup so that while it might be reasonably to say check if login works on mobile and desktop, if the request wasn't incredibly specific it is better to submit it working on desktop, not check it on mobile, and wait for the breaking ticket. For a lot of reasons checking it on mobile vs not desktop (bad example) will actually have people asking why it isn't done. This isn't explicit of course but the feedback loop it creates of not thinking outside the ticket means releases are on the scale of months, the releases are seen as stable only because they're incredibly atomic and narrow and developer turnover is high.
But we have some developers that really want change and unfortunately this mainframe style application is the last one in the organization we can't get rid of. All the Java applications have forced their way through a now approved and sanctioned backdoor of Docker. This was only because they were able to run their entire CI/CD process locally, then give it to the infrastructure team to run their CI/CD process. They were getting giant amount of features done without fretting about a system they had no control over. And they were getting those features done without bugs.
There's a lot to unpack here and a lot of it is not technical in nature but the management structure doesn't see themselves as needing a new way of overall approaching software development but finding yet another tool to speed things up. They can't change the legacy program but they can change from Javscript to Typescript, see an article about how Typescript improves productivity and then mandate everyone uses that.
I have a lot of sway but I cannot change their legacy app or their way of thinking without doing what the Java team did and prove the new method works.
Again this is an organization that plans for deployments by having everyone up to 2AM as the 200+ production servers are manually updated. This is not even the fake fun of the late 90s lets have pizza and beer while pulling an all-nighter, this is a bunch of people in suits sitting in a hot conference room. I'm in the odd position of having to change this little by little and hopefully getting some early victories so that I can go to upper management.
The real problem is the board is old and the average age is around 75 without exaggeration. Legal has a huge influence which is also about the same age and bills a lot of hours to deny things like React because React hasn't passed some sort of data security thing. There's never really a straight answer but they have no real incentive to give an okay on something. But this is way off topic.
posted by geoff. at 1:49 PM on October 31, 2020
Response by poster: It looks like the previous consulting team did something similar which was trying to solve the obvious over-arching problems, then solving the immediate problem at hand which would have gotten the particular minor feature out the door but not faster or even high quality just in a different way and then they were eventually oddly rejected and quit the client.
I've dealt with this situation before in enterprises where it is like someone coming to you and wanting to lose weight and look good but not wanting to diet or exercise and fundamentally you could come to me wanting an exercise program then rejecting anything that involves motion then complain you didn't change even though you hired the best fitness instructor.
I'm thinking out loud at this point but I'm beginning to think that based on my previous experiences where no matter how hard I tried or objectively what good job I did in a large enterprise the goal is simply not to get fired. That maybe instead of being optimistic that I can work within an enterprise's structure and Kafkaesque rules, maybe I need to say I don't want to hear things can't be changed or that it's on a roadmap. That yes today we need to stop and change things and things can't be done in parallel or do things like "waterfall and agile at the same time." I know this will result in a "cross-functional change management team" to evaluate the situation but in the end nothing will change about anything until the vendor drops support or the situation gets so bad they can't do things like get features out. There's no motivation otherwise.
I might just cut my losses now, give them a report on what they need to change and be honest and firm about it not needing to be taken piece-meal or Frankenstein it then never deal with a team with literally hundreds of Oracle and Arthur Anderson consultants milling about while management wonders why it takes so long and is so expensive yet shoots down any idea as to make it better. Too bad a lot of these large enterprise government type institutions have attractive benefits and good work life balance outside of the aforementioned crazy deploys.
posted by geoff. at 2:23 PM on October 31, 2020
I've dealt with this situation before in enterprises where it is like someone coming to you and wanting to lose weight and look good but not wanting to diet or exercise and fundamentally you could come to me wanting an exercise program then rejecting anything that involves motion then complain you didn't change even though you hired the best fitness instructor.
I'm thinking out loud at this point but I'm beginning to think that based on my previous experiences where no matter how hard I tried or objectively what good job I did in a large enterprise the goal is simply not to get fired. That maybe instead of being optimistic that I can work within an enterprise's structure and Kafkaesque rules, maybe I need to say I don't want to hear things can't be changed or that it's on a roadmap. That yes today we need to stop and change things and things can't be done in parallel or do things like "waterfall and agile at the same time." I know this will result in a "cross-functional change management team" to evaluate the situation but in the end nothing will change about anything until the vendor drops support or the situation gets so bad they can't do things like get features out. There's no motivation otherwise.
I might just cut my losses now, give them a report on what they need to change and be honest and firm about it not needing to be taken piece-meal or Frankenstein it then never deal with a team with literally hundreds of Oracle and Arthur Anderson consultants milling about while management wonders why it takes so long and is so expensive yet shoots down any idea as to make it better. Too bad a lot of these large enterprise government type institutions have attractive benefits and good work life balance outside of the aforementioned crazy deploys.
posted by geoff. at 2:23 PM on October 31, 2020
As much as you've told us, i think there's still a lot of missing context. Like i think now you're talking about devs actively working on this application? I got the impression you just wanted to run an instance of it and didn't like Windows for some reason.
Anyway, good luck.
posted by Horselover Fat at 2:37 PM on October 31, 2020 [1 favorite]
Anyway, good luck.
posted by Horselover Fat at 2:37 PM on October 31, 2020 [1 favorite]
Response by poster: Like i think now you're talking about devs actively working on this application?
Yeah I just found about that today looking around there's another team separate to mine that's actively working on it. I was asked why I wasn't told and was told I didn't need to worry about that. Sorry about the confusion, just found out myself.
posted by geoff. at 2:43 PM on October 31, 2020
Yeah I just found about that today looking around there's another team separate to mine that's actively working on it. I was asked why I wasn't told and was told I didn't need to worry about that. Sorry about the confusion, just found out myself.
posted by geoff. at 2:43 PM on October 31, 2020
Response by poster: So yesterday I thought I just had to isolate and today I found out a large portion of the problem isn't that they needed to make a few changes in the app to get what they wanted such as changing the identity of a logged in user sort of thing, but there was active development on it but that I'd be able to do all I needed to do without worrying about it which lead to my long rant.
So yes, if the legacy app isn't in isolation my original question is invalid and I kind of went on a long how am I supposed to help you when I ask things like "Is it still being developed on?" and someone says no so I don't have to ostensibly worry about it. And not a casual no, but an all hands on deck head of department no. Again, this seems like an organization where everyone has their fiefdoms they protect pretty ferociously.
I've played this thing before and treating the app like it was a legacy app won't help as it seems being dumb about it gets me in trouble too. So if I developed good practices assuming the app was not being developed on, and it broke because it was being developed on suddenly there'd be a finger pointing game.
posted by geoff. at 2:51 PM on October 31, 2020
So yes, if the legacy app isn't in isolation my original question is invalid and I kind of went on a long how am I supposed to help you when I ask things like "Is it still being developed on?" and someone says no so I don't have to ostensibly worry about it. And not a casual no, but an all hands on deck head of department no. Again, this seems like an organization where everyone has their fiefdoms they protect pretty ferociously.
I've played this thing before and treating the app like it was a legacy app won't help as it seems being dumb about it gets me in trouble too. So if I developed good practices assuming the app was not being developed on, and it broke because it was being developed on suddenly there'd be a finger pointing game.
posted by geoff. at 2:51 PM on October 31, 2020
Response by poster: For posterity here is my Dockerfile with Apache, mod_mono corresponding to the latest mono at roughly 4.7.0. Note that mono stipulates 4.7 and not the minor-minor version.
posted by geoff. at 3:49 PM on October 31, 2020
posted by geoff. at 3:49 PM on October 31, 2020
I'm not interested in this topic but I was surprised at the imbalance of answers. Mods have previously clarified that AskMe isn't a space for back-and-forth. geoff., out of the 12 answer on this post, 8 of them are from you. The combination of all your answers is an outline for a blogpost or could have been asked and answered easily on forums like stackoverflow or one of the sub-reddits.
posted by lemon_icing at 4:27 PM on October 31, 2020 [3 favorites]
posted by lemon_icing at 4:27 PM on October 31, 2020 [3 favorites]
Yeah, there is a lot going on here that seems irrelevant to your original question. I am having trouble following your story but in general I will say that .NET Framework -> .NET Core migrations without source code are uncommon and the prospect rings a lot of THERE BE DRAGONS alarm bells for me.
posted by ripley_ at 9:07 PM on October 31, 2020 [1 favorite]
posted by ripley_ at 9:07 PM on October 31, 2020 [1 favorite]
Nice catch Horselover Fat : circumvention of licensing. This kind of exposure is not beneficial to your company. Have you notified your CTO or CIO or whoever signs the licensing agreements? This type of decision is well above the paygrade of a developer.
posted by lemon_icing at 12:05 PM on November 1, 2020
posted by lemon_icing at 12:05 PM on November 1, 2020
« Older How best to get safely from Olympia WA to SF Bay... | so is Bobby from Queer Eye going to help me or... Newer »
This thread is closed to new comments.
It sounds like you're in quite a different position since you mention that the application is supplied by a vendor, you dont have the code, and there are DLLs.
I'm not familiar with mono or .NET but the mono website has an ASP.NET compatibility FAQ and a second FAQ that talks about mono supporting .NET framework 4.7 with some caveats.
posted by are-coral-made at 10:06 PM on October 30, 2020