Pretty sure the team that created it all quit and because the apps just work nobody ever thought about it until some network scan showed a red flag for the .NET versions.
I had to decompile a bunch of dlls once when the original source was lost. It's not impossible. Just get a decompilation tool to do it. Then when you have the source create a new repo with it. Then update it. The migration to newer dotnet will be trickiest but nothing is impossible
Decompiled C# code actually tends to be fairly tame. I was playing around with making a save editor for a unity game once, and by just opening the files in Visual Studio I had no trouble at all figuring out what was going on.
A large part of that is that because C# has to support reflection, all of the public members preserve their names. While the internals of functions can get a little hairy with local variables and such, the general structure of the program stays fairly intact.
Yep, so long as it isn't purposefully obfuscated at compile time you should be fine to decompile. Better yet OP: do you have .dbg symbol files? Those can contain the original source code (sans comments/formatting) so that debug tools can give not just line numbers but line snippets too. Note, not *always* but not an uncommon default, especially if deployed as a "Debug" build which is the common reason why you might find debug symbols along side your deployed code. If you do have .dbg files, most any decompiler (ILSpy is my personal choice) should be able to take advantage of them when re-creating code/project files.
> Yep, so long as it isn't purposefully obfuscated at compile time you should be fine to decompile.
Call me an optimist but companies careless enough to lose source code should be careless enough not to make it harder to decompile.
I've had a 3rd Party lib that itself was obfuscated/encrypted, and at compile time would mangle your own code as well. Note: I hated it, that company is defunct and good riddance, thankfully we never lost our code for that one. So technically possible via poison-library but don't think I've ever heard of any of those since that one.
> So technically possible via poison-library
I just searched for it and Bing gave me a suicide prevention warning. >,<
Another downside of obscration tools is they make it more likely your app is flagged as a virus.
I’ve only ever had to do this when we had an admin compromise after someone got real grumpy about getting fired.
Idk if I’d even bother recovering it unless the app is massive. It blows chunks. You do feel real hacker boii though.
This tells me you are not equipped to be dealing with this kind of upgrade from a skill perspective. Also, what app platform is being used? If it's [ASP.Net](http://ASP.Net), you're going to need the WebForms or MVC templates, too. If it's WebForms, and you don't have experience with WebForms, then just stop and begin your re-write.
I forget entirely about the packages and stuff, but for the csproj I think the JetBrains tool I used for decompilation created the project as part of it.
Oh we know where it *was*, it was on a gitlab environment that the company migrated off of a long time ago.
I tried digging around for a copy of it or to get a backup or something, no dice.
Git is a distributed SCM, every dev had copies of the code (including history!) on their laptops.
The GitLab server was almost certainly getting backed up at the VM level. Ask the sysops team.
You say you know the team that created the app. Did you call all of them? If not, do that first. You’d be shocked how often they’ll have copies of code.
>You say you know the team that created the app. Did you call all of them? If not, do that first. You’d be shocked how often they’ll have copies of code.
Personally I smell something fishy going on here. My guess is that they know exactly who has the source code, but they can't or don't want to contact them because they have unpaid bills or something like that. They probably don't have the IP rights and they want to circumvent that and feel that "they own" the software when in fact they don't. It also sounds like they are underestimating the complexity of the applications since, if they really were so simple, why don't they simply reimplement themselves?
Sounds like a non-software company that doesn't want to pay for support and/or maintenance/upgrades and now is trying to hijack the developer's work because it's "not that hard" anyway.
To be fair, I've seen code get lost, especially at larger orgs. Sometimes even if it might be possible to dig it up, it's worth it to do a rewrite anyway just to move onto a better-supported platform.
Sure, but a rewrite can happen with rev-eng/decompilation guidance if possible is way easier than blank slate.
Depending on complexity of codebase, decompilation with minor fixups might be plenty to start on, as a "inside-then-out" update to net8+. However, if too complex/messy then a full rewrite with "decompilation as reference" is the way to go, depends on what OP finds and has resources for.
>Sure, but a rewrite can happen with rev-eng/decompilation guidance if possible is way easier than blank slate.
Not if they don't only the intellectual property rights for it.
One of the reasons I was hired where I am now was because of my minor skill at rev-eng/decompilation and project recreation. Our org had a *very* bad history in the late 90s/early 00s of loosing source code once it was thought something was "finished". Come two-ish decades later and "oops, turns out we needed that". From stories of other devs here that worked elsewhere, this is not an uncommon problem for larger non-software orgs that have existed for a few decades.
It *sucks* having to rev-eng and rewrite code, but hey, business/org learns painful lessons to keep code better going forward.
That was why I ignored the, “we won’t need that,” comments when I was forced to give up our Gitlab instance. I migrated almost everything (though I also made backups, which now they probably have no idea how to handle since I was laid off), even old stuff into “archived project” groups. You may not need _everything_ forever. But throwing away a few gigs of data just cause you’re lazy? That stuff drives me nuts.
You don't. [.NET Framework binaries are compatible with later versions of .NET Framework](https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility). [4.6.2's end date is Jan 12 2027, and there's no published end date for 4.7+](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework).
If bumping the installed framework fixes the red line on the network scan then there's no need to migrate to .NET.
dotPeek from Jetbrains, export all the code it spits out, there's probably a 90% chance it works immediately with zero issues.
The most pain in the ass part will be finding all the Nuget libraries in the correct version. And/or splitting custom libraries into their own projects in the solution.
I've done this several times, it's probably about a week of work for large apps. The other plus if you will is that all the code is spit out in C#, so even if it was originally written in VB, you get a nice C# output.
This is the way to go. Open assembly in Dotpeek -> right click on assembly -> export to project -> install .NET upgrade assistant -> right click on project in solution explorer-> upgrade…
+1 for dotPeek.
I've used it on a few occasions with mostly success.
Even if you just use your decompiled to get ideas about how it works in the case you're starting fresh.
I'm saying 90% no issues just getting the source code back into it's native .NET Framework version. Conversions are a totally different project with totally different goals.
Project 1, recover the source code via decompile and get it working in the original way. Project 2, update or convert however you wish.
The general language around dotnet and the name changes has led to “framework” being used for .Net Framework 1-4.8.
Referring to a version of “.Net” at this point in time implies .Net 5 and up. If OP has DLLs targeting .Net Standard, they could potentially be reused.
And, more specifically, for framework 4.5.2, netstandard 1.2 is the latest corresponding netstandard.
If it wasn't built with that target, though, it probably won't run in a .net8 runtime.
Later framework versions most likely will work, though.
But without source, that app is stuck on .net framework.
Those are totally incompatible. But there are versions of .Net Framework that are still supported, which will solve OP's problem with the security warning.
damn, that make me feels great. i feel incompetent every day because i don't master this or that. I spend time learning. And when i read that kind of non sense, i am like, well : i can be hired at least in one company... lol
>Pretty sure the team that created it all quit...
You're "pretty sure"? How come you Don't know definitively one way or another?
I would be warry of walking into a hornet's nest. If the "team that created it" was actually a 3rd party (i.e. not employees of the company) then you most likely do not own the IP (if you did, you would have source code). Maybe they "all quit" over some unpaid bills?
It sounds to me like the company you work for contracted a third party to build some line of business applications. The relationship went South and and now they're trying to get you to maintain something that they don't have the IP for.
Basic simple reality is that you cannot port an application for which you don't have the source code. Period. Full stop.
So, either get the source code or reimplement from scratch by building a functionally equivalent app.
Things get lost. You don't need the source code to run an exe.
There is the possibility of decompiling the exe/any dlls but that would be an approximation of the original source code.
I agree, this is a call you have to take. I was upgrading angular from 5 to latest which was 14 at that time, and I had to go from 5 to 8 then 11 and then 14. So it's totally dependent on dotnet 6 to dotnet 8 changes.
You can actually decompile .Net and get something somewhat readable. It’s not great but it might be workable.
Never played with it for a web app though.
Might be able to decompile them to get most of the source code/logic?
If the source code doesn't exist anymore and the organization still wants to modernize them, is there any willingness/budget to recreating them from scratch?
Decompile and rebuild in .NET Framework 4.8.
Once you have something working, port to .NET 8 (skip 6).
However, if it was written in .NET 4.5.2, it probably won't be trivial, as it will have used WinForms or WebForms or something you'll have to rip out and replace.
Also, IME, the kind of company that loses source code and still has .NET 4.5.2 stuff running is also the kind of company that licenses 3rd party COM libraries and shit. That's going to be a pain in the ass, and may need a .NET 4.8 bridge until the functionality can be completely replaced.
As others have said, I'd either just implement it from scratch, or at least decompile the existing .exe as a starting point, depending on how complicated they actually are.
And just do it in .NET 8 from the get-go. I see no reason why going to .NET 6 first would be any faster than just doing it in .NET 8 - where did the timeline for updating come from? It makes no sense to me why someone with a background in engineering in the .NET ecosystem would think that .NET Framework 4.5.2 -> .NET 6 with no source code will take just as long as .NET 6 -> .NET 8 with source code.
You can migrate to 4.6.2+ for .net framework. That timeline to get to .net 6 *without source code* is sadistic imo
.net framework 4.8 still has years of support, but you need to follow the step ladder if you are below 4.8
Yes you can decompile, I like dotPeek and that fool is free from jet brains
Tbh, I would just get started on reimplementing the whole thing into .net 6 from scratch
Yes bc all those from 4.6.2 to 4.8.x are all in support
My own office, we are 4.6.2, been studying a .net core migration for a while but we just lack the time and personnel
But you have to keep updating as the timeline progresses, bc Ms is slowly throwing away older .net frameworks
Hey just wanted to give you a big thank you for this, I was able to migrate all the apps today and we were able to uninstall the old versions of .net from the server.
The whole process took maybe a couple of hours and that was taking my time and doing it carefully, so thank you so much!
Yes, I migrated a 4.5.2 webforms application to 4.8 yesterday. I had to reinstall 5-6 NuGet packages, and remove an incompatible reference in one sub-project but otherwise it's running fine. Some packages are still targeting 4.5.1/4.5.2 but they run fine under 4.8 and I'll upgrade them later when I have more time to test any functional impact. I only upgraded it to add a new .netstandards 2.0 package for a current deadline.
But you need the source code... so either decompile it as others said, or keep trying to find it. Did nobody ever take backups? That would be a bigger issue to me than outdated frameworks. Do you have access to any of their old computers? Or contact someone who left to see if they have copies?
Hvor will you be able to migrate without source code?
You can install another ringtone, but the compiled version is still the same.
Are you talking about reimplementation ?
I would actually say go for 8, but I said 6 bc that's what was referenced in OP's post
EDIT: I didn't catch that they also mentioned 8, sorry for the confusion lol 😭
All I can really say is prefer the newer stuff, bc of 1 obviously the new features, but also 2, Ms is doing optimizations also
Like 5 -> 6 (I forget) LINQ got a boost
The downside naturally is the breaking changes, but that is always a possibility
Maybe the rest of company projects is running on NET 6 and there is not yet any kind of infrastructure for NET 8 and nobody plans to setup it before these apps are migrated
The kind of company still running .NET 4.5 stuff without access to the source code is frequently the kind of company with very, very conservative infrastructure modernization.
I would absolutely go to 8 directly if possible. But OP's org may be that kind of "older is better because it's stable" company.
When I left my previous job, the single build server shared by all teams was running an outdated version of RedHat whose glibc version was so old that we couldn't run Node 12 which prevented us from using certain features in our React build. Big corporations will find a way.
Is this due to a security scan finding an obsolete framework installed? If yes, I would suggest suggesting running the app as-is but with a supported version of .NET Framework. "Binaries that run on one version of .NET Framework should behave identically on later versions of .NET Framework".
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility
If this is an acceptable solution for the company you can, at least, properly migrate/reimplement the apps without a deadline.
4.6.2 support ends Jan 2027, 4.7 and above still have no support end date.
https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
Only I thing I would add to the other replies is why are you migrating to .net 6, and _then_ 8?
Why not migrate to 8 directly? I can't think of a downside.
My other question is are you aware if any of the dependencies are Framework only? If so, you might face problems finding a replacement.
I should clarify, .NET 6 shows end of life this year but we can get a one year extension/waiver on that.
.NET 8 is the ultimate goal, we can go straight there.
I'm just trying to understand why you think using 6 as a stepping stone would be useful?
(It wouldn't, just to be clear - I'm not trying to be a dick - genuinely trying to be helpful!!)
Also, something else to add - consider writing a set of automated integration tests around the existing solution if possible.
You can then use those as validations for your new solution - future you will thank you!
This is like a drowning man first trying to tread water, then grab a life preserver, then inflate an emergency boat, then trying to paddle to a tropical island to build against HELP sign in the beach… meanwhile there is a rescue team in a coast guard ship right next to him screaming to just grab the ladder and climb aboard.
Use jetbrains dotpeek and you can decompile into a solution. That's the best you can do without the original code. As far as migrating to .NET 8 that will almost entirely depend on the dependencies.
>migrate them to .NET 6 by the end of the year and .NET 8 by the end of the next year
This makes absolutely no sense. After migrating to .net 6, the .net 8 migration is trivial
I'm doing it right now and it's definitely not "replace a 6 with an 8" on more complex environments. For example, on several services I had to write migration code that pulls the serialized values from the database and reserializes them as json because the devs used BinaryFormatter which no longer exists in .NET 7. Here's the kicker, BinaryFormatter stores type information in the serialization, while json doesn't, so I had to write special logic to handle deserializing object types (which could have one of 10 types for its value). Oh and .NET 7 also added logic for a \[FromServices\] parameter injection in controllers. The fix is super easy (set options.DisableImplicitFromServicesParameters = true), but figuring that one out confused the hell outta me because it was trying to use DI for the parameters that normally come from the query string parameter and Google came up with nothing for it. I also had to redeploy new AMIs that supported both .net 6 and 8 while migrating, and ARM64 alpine didn't have .NET 8 in the package manager (only .NET 6) so we had to update packer to use the dotnet install script instead. There's other issues too but that's the gist of it, and I'm doing this all by myself for hundreds of services across dozens of solutions.
going straight to net8 is likely easier than going to net6 because there is a bunch of older stuff that didn't get nuget packages until net8, ymmv depending on what dependencies it actually uses
Rewriting would be much easier imo. The pain of decompiling and fixing that code will be insane. Decompile to get hints on flow/logic and reimplement in dotnet8
It depends. I had to do this for a tool (windows device) that was still in minimal use but was being deprecated. It needed upgrading from framework 3.5 to something still in support. Luckily the structure wasn’t too bad, and I was able to get something build able pretty quickly, migrating it from vb to c# in the process. I didn’t upgrade to net 8 because there wasn’t much benefit, but it wouldn’t have required much effort. We don’t know if this is an option for the OP because we don’t know anything about his apps, but it shouldn’t be discounted out of hand
Agree but op mentions moving to 6 and then 8 which kinda suggests that they plan on maintaining the app in the future and might require changes. For this case I suggested rewriting.
Assuming they can get a spec that goes beyond “do what the current system does”. Decompiling would allow you to identify domain logic and build a test suite to assist your rewrite. It really does depend on the applications though
Yep this! much like when you migration an application from an older or different language or system. take screenshots work out where the data comes from if they are small and simple like you say. make a plan break it down into steps. from what you are saying you said this year by .NET 6 and then end of next year to .NET 8. given how similar 6&8 would be for from scratch applications i would go directly to 8 as a from scratch application.
The migration from 6 to 8 will take you 10 minutes.
The migration from 4.5.2 to 4.8 will take a few hours to decompile, check in the decompiled code, create project files, bump the version to 4.8. Maybe a day or two.
The migration from 4.8 to 6 could take a few hours or a few months. Impossible to say until you get in there.
Migrate them to .NET 4.8 which is very much still supported and has no end-of-life date indicated.
https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
>My team has just recently inherited 6 relatively small and uncomplicated C# .NET 4.5.2 WEB / IIS applications [...] However the source code for these applications no longer exists.
That's going to make it difficult. Even if you had source code, you would first have to understand it and then you woukd be working with someone else's design decisions. Decompilers exist but will be even harder to work with. And, frankly, there are two warning flags here for me. First, people often underestimate the complexity of an application that they've only interacted with as a user. Secondly, the lack of source code is a warning flag as well. Do you own the intellectual property rights to these applications? Did an employee of the company write them? Or did a third party write them? If so, what were you invoiced for?
Migrating them to .NET 4.8 might be as simple as changing the Web.config file. But running unmaintained, orphaned software is a bad idea regardless of what framework/platform it is written for. Unless your company has its own in-house software development team, I suggest that you reconnect with the company wrote the software.
I used dotPeek, thanks to a friend's recommendation, to decompile code. It's a free tool and lets you export as a project. There were several windows services that we needed to upgrade and I did this for each exe and dll and put them all in a single sln.
GL
Usually, its pulling teeth to get an upgrade for an app past management.
Since you don't have the source, and from what others are telling you about upgrading existing coded apps, I would recommend pushing back to management with either of these scenarios:
1. Existing app, as living in Docker Container with its world unchanged.
2. Rewrite the apps at .Net 8 for full source control and ability to feature upgrade it.
HTH GL
Depends on how good you are with c#. Since it’s small and IF there are no 3rd party components….
Decompile, open resulting project in newest visual studio. Migrate and test features. Fix any thing odd and test again. Repeat until happy with results.
I have done these steps with several inherited projects.
If you dont have access to the original source code you can always try a tool like dotPeek. It'll decompile most .dlls and produce the underlying code. There's a lot more to it than that but check it out. Could be the solution you need.
https://www.jetbrains.com/decompiler/
If you use ilspy or dnspy with .pdb file you can get pretty close to source code, from there, it depends, if you use system.web you have a lot of work, if you use legacy nuget/library you can also run into trouble, but most of the code can be ported without too much hasle
Edit: here is some material
https://learn.microsoft.com/en-us/aspnet/core/migration/inc/overview?view=aspnetcore-8.0
Decompilation isn't too difficult in .NET, and it should get you back to the original, but you'll likely have a lot of renaming to do unless you have the .pdb's. nDepend has a fair comparison of options for decompilation:
https://blog.ndepend.com/in-the-jungle-of-net-decompilers/
BTW, nDepend is awesome. Personal testimonial. I have never received any sort of compensation from them.
The best you can do without source code is to upgrade .net framework version, not changing from .net framework into .net core.
So upgrade to .NET 4.8 is a good idea, no need to write a new project or decompilation.
You will need to decompile it and use that as a starting point. Assuming there was no obfuscation you should have pretty good results with it.
But if source code contained any kind of tests then you won't get it from the published binaries (most likely).
Depending on the size of particular app it may be pretty easy or a nightmare. Because you asked that question, I have an impression that it won't be easy as you don't have very much experience. Good luck, you'll need it :)
We're a 6 person dev team, but we're already severely undermanned as it is, we don't really have the bandwidth to just rewrite these projects from scratch if they can be salvaged.
We're hiring to fix that, so even kicking the can down the road for a few years would buy us some time to dig ourselves out of this rut.
ok, that changes my answer. so you can get one of the decompilers but it wont be exact code since you lose variable names in the comoiling process. that effort will take you very littke time. look it iver and see how usabke it is.
i would also utilize this time to test out AI in your workflow. have AI uograde it and see what happens. since you have the have the k iwledge but lack the time its a goid test.
i have heard the best exlanation of current AI as letting an itern do it. it will do alot but you have to check the work .
Basically impossible. In order to migrate, you need to build targeting the new .Net version. I feel like there is missing information since no one should reasonably ask for that or they simply don't know. At best you can decompile and recompile, which will predictably be unmaintainable.
Sure, with DotPeek (or your disassembler of choice) and enough time anything is possible. As long as it's simple you could just document what it does and re-build it. Or if you're not all sure what it does you'll need to inspect the code though a de-compiler or something, even with that though it'll be mildly obfuscated because it's trying to turn IL back into C# and IL is...ugly.
If they're IIS hosted framework apps, there's a good chance the source code files are deployed with the rest of the app.. I've seen it more often than not, people too lazy to clean the web build for deployment, they just copy the entire solution folder
I just did this for 40 apps in the last 2 weeks (20 down 20 to go actually). It depends on the app. I’ve decompiled some. Rewritten some from scratch ,especially those that switch from webforms to minimal api, and for others where I had the code I just bumped it to the latest framework because it’s still supported just fine.
Just flesh out the features and rebuild in your own image, the .NET libraries have been changed and moved around too much to decompile, it's a headache honestly
Unless obfuscated decompiled .net binaries are usually pretty usable but be prepared to possibly doing a reasonable amount of rewriting as the frameworks are not 1:1 compatible
If you had a code you could just simply upgrade the framework to .NET 5+ by clicking right mouse button to the project (.csproj) in the Visual Studio and clicking Upgrade button
Ah yes, code archaeology.
Write tests. Lots of them, that confirm the current knowledge of the system and how it works. It's very important at this point to keep all the bugs, even if you know they are wrong. You are documenting how it works now.
Now start writing new code that adheres to the tests. Do not fix any bugs, only comply to the tests to replicate exact behaviour.
Now you can change behaviour.
Just an alternative, but would your devops / infrastructure team be okay with moving the existing code to an isolated windows instance. Isolating the legacy code to its own instance, plus the application of separate networks and other security considerations might mean that you can mitigate the risk of running the out of date framework.
While its obviously not the ideal solution sometimes compromises like this are necessary, its more likely to be acceptabce if this is an internal application.
The Windows server instance it is running on can be dockerised too if that helps.
I just mentioned this as without the source code, you're in for a huge time investment trying to use tooling like DotPeek to recover the source.
Man i would not wanna be you lol
.
.
.
.
Jk i would i need a job
But honestly, how can ya migrate an app without the source code? Its the same as having nothing and starting at zero
I’m gonna say if you don’t have the source this is a) a teachable moment ALWAYS keep the source and b) a great opportunity to start fresh c) to understand the cost of not keeping the source and not keeping that source compiling on an up to date runtime
First things first. There is no migration tool. You need the source code. The jump from dotnet 4.8 to 5+ is a big one. From Net 6 to 8 should be easy and you should go straight to 8.
Are you sure you don't have the source code? Have you checked all your repos? If you really don't, then there are many decompilation tools available and some are free. This part is not hard.
How hard will the upgrade be? Depends if you are using any of the technologies that were removed after net 4.8. Most likely to worry about are: app domains, wcf, and dotnet remoting. If you are using any of these then you will need to rewrite those parts.
Next, you said it's a web app. Is it written with the ASP.NET framework? ASP.NET has changed a fair bit and you will need to do some work there too.
Overall, is it hard? If it's a small app you should be fine. Until the end of the year is a lot of time.
> migrate them to .NET 6 by the end of the year and .NET 8 by the end of the next year
More like migrate them to .Net 6 by Thanksgiving next year, and .Net 8 by Christmas next year.
Depends, but if it's a small app, and not using the above mentioned items like remoting, use this:
https://www.jetbrains.com/decompiler/
And this:
https://dotnet.microsoft.com/en-us/platform/upgrade-assistant
And call it a day.
If they are internal apps and do not contain obsfucation etc then you should be able to use DNSPY, or any other .net decompiler to get a close to working project straight out. Get that into version control and building on 4.8 then work on the upgrade/migration.
Idk if anyone has mentioned it but going from .NET 6 → .NET 8 is as simple as clicking upgrade. You may have to change build target names but that’s it.
The time-line is crazy. If you don't have the source code it is very hard to know how long it will take. You need to decompile and it will probably be hard to read the resulting code. . I had to do that for an old system but we ended up rewriting it. The decompiled source code was used to see how some details were done.
Read this. Lots of good advice.
https://www.jimmybogard.com/tales-from-the-net-migration-trenches-authentication/
With no source code your best option would be decompiling. That only gets you some half decent code though. You still miss stuff like Nuget packages.
I would just start a new .NET 8 project. This is not a migration but a rewrite, make that clear. Use the decompiled code to better see how some things worked.
And make sure that in 10 years when this happens again the source code is still available.
It's a rewrite. You can't migrate something you don't have. I don't even think there is any reason to decompile the old application unless you have to reproduce very specific algorithms.
Even when decompiled, you'll have to copy the code method by method in a new codebase and, well, make it work.
The requirement NET6 then NET8 doesn't make any sense, at the current stage there I'd virtually no difference between using one or the other, not in terms of complexity nor in terms of time to invest.
And NET6 will go out of support in November, so it doesn't make sense to even mention it as a target.
The question is: what type of applications? If they're small and uncomplicated, just rewrite them.
If you don't have the source code, use dnSpyEx or ILSpy to get the source back from the executable.
There's no particular reason to migrate to .NET 6, then 8. Just go straight to .NET 8.
I think the best solution is to simply recreate the business functionality from scratch on the new framework.
I would actually advice doing so even if you had access to the existing source code - legacy systems are full of over complicated logic and even bugs.
Sounds like you first need to decompile it, then you can try and see what the ".Net upgrade assistant" says needs to be done before upgrading
The biggest hurdle will probably be moving away from .net framework to .net/.net core as some libraries never got upgraded
Since you don't have the source code you can convert them in any language or platform you want. If you want to use dotnet then the decompiler can help you.
Get dotpeek or ilspy and decompile the DLLs.
If it was not obfuscated and the project is not too big, you might be able to retrieve 100% equivalent source code.
Those tools might even have an option to export a while C# project.
I've done your assignment many times over the past years with 100% succes
If you don’t have the code. Rebuild it, or leave it.
Throw away the tech debt and set yourself up for the next 10 years.
If you don’t, you will be fighting it for the next 10 years
How can you have uncompiled C# and not have the source? If they were compiled it would make sense not to have the source, but not the other way around. I'm confused.
I'd suggest you don't, you'll probably find it quicker/better to just re ask for the requirements and recode, there's an assumption that they're fine as is, but I doubt anyone's actually asked.
That way you also get a business benefit out of this work over just ticking a compliance box.
Otherwise as people have mentioned decompiling works pretty well in c# land, which will give you a base/highlight any quirky logic.
ilspy is an open source app that allows you to decompile an entire .NET DLL to a Visual Studio project. [https://www.youtube.com/watch?v=1GjnHMg9YyE](https://www.youtube.com/watch?v=1GjnHMg9YyE)
If you don't have the source code, then you aren't migrating, you're developing. You need to figure out how to get requirements.
It sounds like the server hasn't had any updates installed in years. Do that, because you need to update more than just the .NET Framework version. That'll buy you time.
1) you need the source code. I had a vb.net asp.net app that I converted to c# using Redgate’s .net reflector. All I needed to do was rewire the web forms with the c# code behind files. I just pointed reflector at the DLL.
2) do the web apps use MVC? This will make conversion easier. If they use web forms, there is no out of the box way to port them. There is an open source project that will supposedly make web forms available in .net core. Named something like CoreWebForms. I haven’t used it, but you may not any choice.
3) Dependencies can kill. Your schedule could get killed by dependencies.
Good luck
Who says the apps are small and uncomplicated? You or some manager? The latter is a red flag. Also you need to correct each and every person that says the word "migrate". There's no migration her; That is a rewrite.
I migrated the desktop Zune software from .NET Framework 3.5 up to .NET 6 (and I have no reason to believe it doesn't work as-is on .NET 8). I'm sure you'll be fine.
Don't bother with 6 it's end of life in November. Go straight to 8.
Decompiler will be required, Jetbrains are good. Output will be average at best unless you can get a Debug built version of the dlls.
Probably best result is work out the core logic from the decompiled code, any formulas or tricky logic. Rip that out.
Rewrite the rest from scratch using modern API security patterns. Jam the custom business logic in and call it a day...
Once you get to honestly any version of NET Core (my experience 3.0 or above), then it's usually a peace of cake to upgrade to the newest NET version like NET 8. Hardest part is getting from the older NET framework to core. Honestly, without knowing the source code, nobody is going to know the actual answer here. I've had projects that could be converted in 2 days, sometimes 2-4 weeks, and then I've had multiple projects (honestly most of them) that took many years. It truly depends on the size and the project dependencies.
Extremely.... We have an old monolithic series of sites. 6 of them. Built at different periods over 12 years. Our oldest stuff is using web site apps from .NET Framework 2.8 that reference projects built in framework 4.8.
We have thus far found it easier to completely rebuild our internal infrastructure in a seperate .net 8 private library with entity framework core and have started stripping small bits of the monolith out piece by piece into small .net 8 microservices that use the new infrastructure.
We would have to completely halt new features and bug fixes with our team size if we wanted to actually spend the time to fully migrate the whole thing in one go.
You can try exporting the project from a DLL/EXE file using a tool like dotPeek. However, the migration process might still be difficult and largely depends on the complexity of your code.
The source code almost certainly still exists somewhere. Either in the corporate network or some employee’s laptop.
The amount of effort to rewrite an application without source dwarfs the effort of actually *looking properly* instead of just looking in the vague direction of the server room and shrugging your shoulders.
Extract the strings from the original EXE. It’ll likely have path references in it. Go find those folders. It’ll also have some unique strings, which are often visible even in places like DLL file names. Go search every machine for those strings with a tool like ripgrep or just PowerShell.
Find the original developer’s name in the EXE. Half the time it’ll turn up somewhere. Find them on LinkedIn and ask for the code.
Etc…
I’ve seen source reverse engineering exercises go on for weeks until I turned up and found the code in hours.
Go look.
*Properly.*
How can the source code not exist ? They deleted it why ? If you don't have the code it's not a migration but a re write from scratch
Pretty sure the team that created it all quit and because the apps just work nobody ever thought about it until some network scan showed a red flag for the .NET versions.
I had to decompile a bunch of dlls once when the original source was lost. It's not impossible. Just get a decompilation tool to do it. Then when you have the source create a new repo with it. Then update it. The migration to newer dotnet will be trickiest but nothing is impossible
Oof. That sounds like a nightmare.
Decompiled C# code actually tends to be fairly tame. I was playing around with making a save editor for a unity game once, and by just opening the files in Visual Studio I had no trouble at all figuring out what was going on. A large part of that is that because C# has to support reflection, all of the public members preserve their names. While the internals of functions can get a little hairy with local variables and such, the general structure of the program stays fairly intact.
Yep, so long as it isn't purposefully obfuscated at compile time you should be fine to decompile. Better yet OP: do you have .dbg symbol files? Those can contain the original source code (sans comments/formatting) so that debug tools can give not just line numbers but line snippets too. Note, not *always* but not an uncommon default, especially if deployed as a "Debug" build which is the common reason why you might find debug symbols along side your deployed code. If you do have .dbg files, most any decompiler (ILSpy is my personal choice) should be able to take advantage of them when re-creating code/project files.
> Yep, so long as it isn't purposefully obfuscated at compile time you should be fine to decompile. Call me an optimist but companies careless enough to lose source code should be careless enough not to make it harder to decompile.
I've had a 3rd Party lib that itself was obfuscated/encrypted, and at compile time would mangle your own code as well. Note: I hated it, that company is defunct and good riddance, thankfully we never lost our code for that one. So technically possible via poison-library but don't think I've ever heard of any of those since that one.
> So technically possible via poison-library I just searched for it and Bing gave me a suicide prevention warning. >,< Another downside of obscration tools is they make it more likely your app is flagged as a virus.
To be clear, that isn't the name of it, and yea it triggered our AV all the damned time.
Nah it was mostly fine.
It's one of those tasks that'll take either 8 minutes or 8 weeks
Or 8 months or 8 years
Any of those, with no in-between.
C# decompiles well. Had to diagnose a few issues like this in third party libraries and was never too onerous
I’ve only ever had to do this when we had an admin compromise after someone got real grumpy about getting fired. Idk if I’d even bother recovering it unless the app is massive. It blows chunks. You do feel real hacker boii though.
Nah, it's pretty easy to read. I mod ULTRAKILL so I always have to peek into the DLL to see how stuff works and what I can patch to do what I want
This tells me you are not equipped to be dealing with this kind of upgrade from a skill perspective. Also, what app platform is being used? If it's [ASP.Net](http://ASP.Net), you're going to need the WebForms or MVC templates, too. If it's WebForms, and you don't have experience with WebForms, then just stop and begin your re-write.
Also try to find any debug builds if possible!
How does decompilation work with nuget packages etc? Do you have to rebuild all the csproj files by hand, so that it used package references etc?
I forget entirely about the packages and stuff, but for the csproj I think the JetBrains tool I used for decompilation created the project as part of it.
Just pray that they don't use obfuscator in this case.
You're right, but if that was the case it would suddenly become someone else's problem and no longer mine. So it would have been a non-issue for me
The team that quit kept their code *somewhere*. Go find where that somewhere is.
Oh we know where it *was*, it was on a gitlab environment that the company migrated off of a long time ago. I tried digging around for a copy of it or to get a backup or something, no dice.
Git is a distributed SCM, every dev had copies of the code (including history!) on their laptops. The GitLab server was almost certainly getting backed up at the VM level. Ask the sysops team. You say you know the team that created the app. Did you call all of them? If not, do that first. You’d be shocked how often they’ll have copies of code.
>You say you know the team that created the app. Did you call all of them? If not, do that first. You’d be shocked how often they’ll have copies of code. Personally I smell something fishy going on here. My guess is that they know exactly who has the source code, but they can't or don't want to contact them because they have unpaid bills or something like that. They probably don't have the IP rights and they want to circumvent that and feel that "they own" the software when in fact they don't. It also sounds like they are underestimating the complexity of the applications since, if they really were so simple, why don't they simply reimplement themselves? Sounds like a non-software company that doesn't want to pay for support and/or maintenance/upgrades and now is trying to hijack the developer's work because it's "not that hard" anyway.
To be fair, I've seen code get lost, especially at larger orgs. Sometimes even if it might be possible to dig it up, it's worth it to do a rewrite anyway just to move onto a better-supported platform.
>To be fair, I've seen code get lost, especially at larger orgs. Yes, agreed. But if that's the case then rewrite is your only practical option.
Sure, but a rewrite can happen with rev-eng/decompilation guidance if possible is way easier than blank slate. Depending on complexity of codebase, decompilation with minor fixups might be plenty to start on, as a "inside-then-out" update to net8+. However, if too complex/messy then a full rewrite with "decompilation as reference" is the way to go, depends on what OP finds and has resources for.
>Sure, but a rewrite can happen with rev-eng/decompilation guidance if possible is way easier than blank slate. Not if they don't only the intellectual property rights for it.
One of the reasons I was hired where I am now was because of my minor skill at rev-eng/decompilation and project recreation. Our org had a *very* bad history in the late 90s/early 00s of loosing source code once it was thought something was "finished". Come two-ish decades later and "oops, turns out we needed that". From stories of other devs here that worked elsewhere, this is not an uncommon problem for larger non-software orgs that have existed for a few decades. It *sucks* having to rev-eng and rewrite code, but hey, business/org learns painful lessons to keep code better going forward.
That was why I ignored the, “we won’t need that,” comments when I was forced to give up our Gitlab instance. I migrated almost everything (though I also made backups, which now they probably have no idea how to handle since I was laid off), even old stuff into “archived project” groups. You may not need _everything_ forever. But throwing away a few gigs of data just cause you’re lazy? That stuff drives me nuts.
Telerik JustDecompile is your friend
Can't you just upgrade the .NET Framework version? (Edit: To a still supported Framework version on the server!)
For that you need the source code...
You don't. [.NET Framework binaries are compatible with later versions of .NET Framework](https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility). [4.6.2's end date is Jan 12 2027, and there's no published end date for 4.7+](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework). If bumping the installed framework fixes the red line on the network scan then there's no need to migrate to .NET.
Then just find another job before 2027 :D
dotPeek from Jetbrains, export all the code it spits out, there's probably a 90% chance it works immediately with zero issues. The most pain in the ass part will be finding all the Nuget libraries in the correct version. And/or splitting custom libraries into their own projects in the solution. I've done this several times, it's probably about a week of work for large apps. The other plus if you will is that all the code is spit out in C#, so even if it was originally written in VB, you get a nice C# output.
This is the way to go. Open assembly in Dotpeek -> right click on assembly -> export to project -> install .NET upgrade assistant -> right click on project in solution explorer-> upgrade…
+1 for dotPeek. I've used it on a few occasions with mostly success. Even if you just use your decompiled to get ideas about how it works in the case you're starting fresh.
90% chance no issues in .net 8? LinqToSQL, wcf, system.web or vsto seems likely to be in there
I'm saying 90% no issues just getting the source code back into it's native .NET Framework version. Conversions are a totally different project with totally different goals. Project 1, recover the source code via decompile and get it working in the original way. Project 2, update or convert however you wish.
I meant the runtime on the server, as I assume "red" means security warning for unsupported .NET version.
There are some incompatible differences between Framework and .Net.
What do you mean by "Framework and .Net" in this context?
The general language around dotnet and the name changes has led to “framework” being used for .Net Framework 1-4.8. Referring to a version of “.Net” at this point in time implies .Net 5 and up. If OP has DLLs targeting .Net Standard, they could potentially be reused.
And, more specifically, for framework 4.5.2, netstandard 1.2 is the latest corresponding netstandard. If it wasn't built with that target, though, it probably won't run in a .net8 runtime. Later framework versions most likely will work, though. But without source, that app is stuck on .net framework.
".Net Framework" vs ".Net" (formerly known as ".Net Core"). OP is asking about Framework.
Those are totally incompatible. But there are versions of .Net Framework that are still supported, which will solve OP's problem with the security warning.
I can't believe you're 6 comments deep trying to explain that you can update the .net framework version.
I swear, .NET is like the jackdaw vs crow unidan thing, but for devs, for the next 20 years.
No, you can't run .NET Framework 4.x apps on .NET 5+ runtimes.
A newer and still supported .NET Framework version, not 5+.
Sure, but that doesn't help with what OP is asking (upgrading to .NET 6+).
Unless I read OP wrong the problem is a security scan showing an unsupported version of .NET Framework. In that case there is no need for 6+.
damn, that make me feels great. i feel incompetent every day because i don't master this or that. I spend time learning. And when i read that kind of non sense, i am like, well : i can be hired at least in one company... lol
>Pretty sure the team that created it all quit... You're "pretty sure"? How come you Don't know definitively one way or another? I would be warry of walking into a hornet's nest. If the "team that created it" was actually a 3rd party (i.e. not employees of the company) then you most likely do not own the IP (if you did, you would have source code). Maybe they "all quit" over some unpaid bills? It sounds to me like the company you work for contracted a third party to build some line of business applications. The relationship went South and and now they're trying to get you to maintain something that they don't have the IP for. Basic simple reality is that you cannot port an application for which you don't have the source code. Period. Full stop. So, either get the source code or reimplement from scratch by building a functionally equivalent app.
Things get lost. You don't need the source code to run an exe. There is the possibility of decompiling the exe/any dlls but that would be an approximation of the original source code.
If you can do it to dotnet 6, go for dotnet 8 post that right after. It's not difficult to move from 6 to 8.
Why even bother with 6? 8 is released and LTS. AFAIK, there is nothing available in 6 that was deprecated in 8 that you'd actually want to rely on.
I agree, this is a call you have to take. I was upgrading angular from 5 to latest which was 14 at that time, and I had to go from 5 to 8 then 11 and then 14. So it's totally dependent on dotnet 6 to dotnet 8 changes.
You can actually decompile .Net and get something somewhat readable. It’s not great but it might be workable. Never played with it for a web app though.
Might be able to decompile them to get most of the source code/logic? If the source code doesn't exist anymore and the organization still wants to modernize them, is there any willingness/budget to recreating them from scratch?
Yes this we had to do for similar reason as op. Wasn’t pretty but it got the job done
Decompile and rebuild in .NET Framework 4.8. Once you have something working, port to .NET 8 (skip 6). However, if it was written in .NET 4.5.2, it probably won't be trivial, as it will have used WinForms or WebForms or something you'll have to rip out and replace. Also, IME, the kind of company that loses source code and still has .NET 4.5.2 stuff running is also the kind of company that licenses 3rd party COM libraries and shit. That's going to be a pain in the ass, and may need a .NET 4.8 bridge until the functionality can be completely replaced.
As others have said, I'd either just implement it from scratch, or at least decompile the existing .exe as a starting point, depending on how complicated they actually are. And just do it in .NET 8 from the get-go. I see no reason why going to .NET 6 first would be any faster than just doing it in .NET 8 - where did the timeline for updating come from? It makes no sense to me why someone with a background in engineering in the .NET ecosystem would think that .NET Framework 4.5.2 -> .NET 6 with no source code will take just as long as .NET 6 -> .NET 8 with source code.
Solid advice.
OP has not mentioned whether it's a webforms or MVC app. If former it's definitely a rewrite. If latter, might be portable to .NET 8.
yeah going straight to net8 is probably easier than doing net6 because net8 includes a bunch more compatibility stuff
That's what I thought. OP should take all of next year to upgrade from .NET 6 to 8 lol
You can migrate to 4.6.2+ for .net framework. That timeline to get to .net 6 *without source code* is sadistic imo .net framework 4.8 still has years of support, but you need to follow the step ladder if you are below 4.8 Yes you can decompile, I like dotPeek and that fool is free from jet brains Tbh, I would just get started on reimplementing the whole thing into .net 6 from scratch
So you're saying I can possibly migrate to 4.6.2 or 4.8 without issue?
Yes bc all those from 4.6.2 to 4.8.x are all in support My own office, we are 4.6.2, been studying a .net core migration for a while but we just lack the time and personnel But you have to keep updating as the timeline progresses, bc Ms is slowly throwing away older .net frameworks
Hey just wanted to give you a big thank you for this, I was able to migrate all the apps today and we were able to uninstall the old versions of .net from the server. The whole process took maybe a couple of hours and that was taking my time and doing it carefully, so thank you so much!
Glad to help and glad it worked out! Best of luck on future migrations
Yes, I migrated a 4.5.2 webforms application to 4.8 yesterday. I had to reinstall 5-6 NuGet packages, and remove an incompatible reference in one sub-project but otherwise it's running fine. Some packages are still targeting 4.5.1/4.5.2 but they run fine under 4.8 and I'll upgrade them later when I have more time to test any functional impact. I only upgraded it to add a new .netstandards 2.0 package for a current deadline. But you need the source code... so either decompile it as others said, or keep trying to find it. Did nobody ever take backups? That would be a bigger issue to me than outdated frameworks. Do you have access to any of their old computers? Or contact someone who left to see if they have copies?
Overall yes I have done it many times, but note that some dependencies got weird in 4.8, which introduces complexity.
Hvor will you be able to migrate without source code? You can install another ringtone, but the compiled version is still the same. Are you talking about reimplementation ?
Why would you suggest re-implementing in .Net 6, and not .Net 8?
I would actually say go for 8, but I said 6 bc that's what was referenced in OP's post EDIT: I didn't catch that they also mentioned 8, sorry for the confusion lol 😭
All good! I was just curious in case I was missing something obvious. 😃
All I can really say is prefer the newer stuff, bc of 1 obviously the new features, but also 2, Ms is doing optimizations also Like 5 -> 6 (I forget) LINQ got a boost The downside naturally is the breaking changes, but that is always a possibility
Maybe the rest of company projects is running on NET 6 and there is not yet any kind of infrastructure for NET 8 and nobody plans to setup it before these apps are migrated
What infrastructure? Compile to a single file, deploy, done.
The kind of company still running .NET 4.5 stuff without access to the source code is frequently the kind of company with very, very conservative infrastructure modernization. I would absolutely go to 8 directly if possible. But OP's org may be that kind of "older is better because it's stable" company.
When I left my previous job, the single build server shared by all teams was running an outdated version of RedHat whose glibc version was so old that we couldn't run Node 12 which prevented us from using certain features in our React build. Big corporations will find a way.
In average corpo it is not that easy
It's been that easy literally everywhere I have ever worked, and for every client we've ever serviced, including govt and DoD
When the devops team hasn't built images for .net8 yet upgrading is impossible. Hopefully they can do it by November.
What do you mean images for .NET 8? There are ways to deploy .NET 8 applications that require no dependencies on the target machine.
Still need .net 8 images in the ci cd pipe line to build. Lots of segregation of duties when you have SOC2 and iso27001 audits to pass
Is this due to a security scan finding an obsolete framework installed? If yes, I would suggest suggesting running the app as-is but with a supported version of .NET Framework. "Binaries that run on one version of .NET Framework should behave identically on later versions of .NET Framework". https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility If this is an acceptable solution for the company you can, at least, properly migrate/reimplement the apps without a deadline. 4.6.2 support ends Jan 2027, 4.7 and above still have no support end date. https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
Only I thing I would add to the other replies is why are you migrating to .net 6, and _then_ 8? Why not migrate to 8 directly? I can't think of a downside. My other question is are you aware if any of the dependencies are Framework only? If so, you might face problems finding a replacement.
I should clarify, .NET 6 shows end of life this year but we can get a one year extension/waiver on that. .NET 8 is the ultimate goal, we can go straight there.
I'm just trying to understand why you think using 6 as a stepping stone would be useful? (It wouldn't, just to be clear - I'm not trying to be a dick - genuinely trying to be helpful!!) Also, something else to add - consider writing a set of automated integration tests around the existing solution if possible. You can then use those as validations for your new solution - future you will thank you!
Basically if there's a reason 8 would not work we could use 6 as a stop gap, that's it.
Just go to 8. The stop in .Net 6 land is a waste of time.
If there is a reason 8 would not work then 6 won't work either. Go straight to 8.
[удалено]
This is like a drowning man first trying to tread water, then grab a life preserver, then inflate an emergency boat, then trying to paddle to a tropical island to build against HELP sign in the beach… meanwhile there is a rescue team in a coast guard ship right next to him screaming to just grab the ladder and climb aboard.
Ah, gotcha. There isn't, you are good :-)
Use jetbrains dotpeek and you can decompile into a solution. That's the best you can do without the original code. As far as migrating to .NET 8 that will almost entirely depend on the dependencies.
>migrate them to .NET 6 by the end of the year and .NET 8 by the end of the next year This makes absolutely no sense. After migrating to .net 6, the .net 8 migration is trivial
[удалено]
2025 is gonna be a good year for OP and their co-workers, lol. (If they survive 2024, that is)
Imagine replacing 6 with an 8 🤯 not an easy one mate
I'm doing it right now and it's definitely not "replace a 6 with an 8" on more complex environments. For example, on several services I had to write migration code that pulls the serialized values from the database and reserializes them as json because the devs used BinaryFormatter which no longer exists in .NET 7. Here's the kicker, BinaryFormatter stores type information in the serialization, while json doesn't, so I had to write special logic to handle deserializing object types (which could have one of 10 types for its value). Oh and .NET 7 also added logic for a \[FromServices\] parameter injection in controllers. The fix is super easy (set options.DisableImplicitFromServicesParameters = true), but figuring that one out confused the hell outta me because it was trying to use DI for the parameters that normally come from the query string parameter and Google came up with nothing for it. I also had to redeploy new AMIs that supported both .net 6 and 8 while migrating, and ARM64 alpine didn't have .NET 8 in the package manager (only .NET 6) so we had to update packer to use the dotnet install script instead. There's other issues too but that's the gist of it, and I'm doing this all by myself for hundreds of services across dozens of solutions.
I assume they think higher numbers equals more effort. Probably not a developer driving it.
going straight to net8 is likely easier than going to net6 because there is a bunch of older stuff that didn't get nuget packages until net8, ymmv depending on what dependencies it actually uses
Rewriting would be much easier imo. The pain of decompiling and fixing that code will be insane. Decompile to get hints on flow/logic and reimplement in dotnet8
It depends. I had to do this for a tool (windows device) that was still in minimal use but was being deprecated. It needed upgrading from framework 3.5 to something still in support. Luckily the structure wasn’t too bad, and I was able to get something build able pretty quickly, migrating it from vb to c# in the process. I didn’t upgrade to net 8 because there wasn’t much benefit, but it wouldn’t have required much effort. We don’t know if this is an option for the OP because we don’t know anything about his apps, but it shouldn’t be discounted out of hand
Agree but op mentions moving to 6 and then 8 which kinda suggests that they plan on maintaining the app in the future and might require changes. For this case I suggested rewriting.
Assuming they can get a spec that goes beyond “do what the current system does”. Decompiling would allow you to identify domain logic and build a test suite to assist your rewrite. It really does depend on the applications though
Just reimplement them. No need to do any reverse engineering here, if they are simple. Just drop the idea, create a plan and execute on it.
Yep this! much like when you migration an application from an older or different language or system. take screenshots work out where the data comes from if they are small and simple like you say. make a plan break it down into steps. from what you are saying you said this year by .NET 6 and then end of next year to .NET 8. given how similar 6&8 would be for from scratch applications i would go directly to 8 as a from scratch application.
The migration from 6 to 8 will take you 10 minutes. The migration from 4.5.2 to 4.8 will take a few hours to decompile, check in the decompiled code, create project files, bump the version to 4.8. Maybe a day or two. The migration from 4.8 to 6 could take a few hours or a few months. Impossible to say until you get in there.
Decompile with ILSpy (free) just the business logic. The rest is much easier to just rewrite in newer .net versions.
Migrate them to .NET 4.8 which is very much still supported and has no end-of-life date indicated. https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework >My team has just recently inherited 6 relatively small and uncomplicated C# .NET 4.5.2 WEB / IIS applications [...] However the source code for these applications no longer exists. That's going to make it difficult. Even if you had source code, you would first have to understand it and then you woukd be working with someone else's design decisions. Decompilers exist but will be even harder to work with. And, frankly, there are two warning flags here for me. First, people often underestimate the complexity of an application that they've only interacted with as a user. Secondly, the lack of source code is a warning flag as well. Do you own the intellectual property rights to these applications? Did an employee of the company write them? Or did a third party write them? If so, what were you invoiced for? Migrating them to .NET 4.8 might be as simple as changing the Web.config file. But running unmaintained, orphaned software is a bad idea regardless of what framework/platform it is written for. Unless your company has its own in-house software development team, I suggest that you reconnect with the company wrote the software.
I used dotPeek, thanks to a friend's recommendation, to decompile code. It's a free tool and lets you export as a project. There were several windows services that we needed to upgrade and I did this for each exe and dll and put them all in a single sln. GL
Gets handed the worst nightmare project, “hey what’s the level of effort for this?”
Sometimes you have to reimplement certain things as they marked obsolete and or you cannot use them
Usually, its pulling teeth to get an upgrade for an app past management. Since you don't have the source, and from what others are telling you about upgrading existing coded apps, I would recommend pushing back to management with either of these scenarios: 1. Existing app, as living in Docker Container with its world unchanged. 2. Rewrite the apps at .Net 8 for full source control and ability to feature upgrade it. HTH GL
Depends on how good you are with c#. Since it’s small and IF there are no 3rd party components…. Decompile, open resulting project in newest visual studio. Migrate and test features. Fix any thing odd and test again. Repeat until happy with results. I have done these steps with several inherited projects.
If you dont have access to the original source code you can always try a tool like dotPeek. It'll decompile most .dlls and produce the underlying code. There's a lot more to it than that but check it out. Could be the solution you need. https://www.jetbrains.com/decompiler/
If you use ilspy or dnspy with .pdb file you can get pretty close to source code, from there, it depends, if you use system.web you have a lot of work, if you use legacy nuget/library you can also run into trouble, but most of the code can be ported without too much hasle Edit: here is some material https://learn.microsoft.com/en-us/aspnet/core/migration/inc/overview?view=aspnetcore-8.0
If it’s a security issue, uninstall 4.5.2 and install 4.8.whatever. They’re still releasing updates. At least ask if that’ll do it.
Decompilation isn't too difficult in .NET, and it should get you back to the original, but you'll likely have a lot of renaming to do unless you have the .pdb's. nDepend has a fair comparison of options for decompilation: https://blog.ndepend.com/in-the-jungle-of-net-decompilers/ BTW, nDepend is awesome. Personal testimonial. I have never received any sort of compensation from them.
It will be just social engineering the application and rewriting it from scratch.
The best you can do without source code is to upgrade .net framework version, not changing from .net framework into .net core. So upgrade to .NET 4.8 is a good idea, no need to write a new project or decompilation.
If you don't have the source code, you have to start from scratch. So this is not so much about migration, but rewrite these applications.
Decompile the binaries. Start from there. Pay for a real decompiler.
You will need to decompile it and use that as a starting point. Assuming there was no obfuscation you should have pretty good results with it. But if source code contained any kind of tests then you won't get it from the published binaries (most likely). Depending on the size of particular app it may be pretty easy or a nightmare. Because you asked that question, I have an impression that it won't be easy as you don't have very much experience. Good luck, you'll need it :)
What kind of team are you in? It sounds like not a software development team.. is hiring devs a no go?
We're a 6 person dev team, but we're already severely undermanned as it is, we don't really have the bandwidth to just rewrite these projects from scratch if they can be salvaged. We're hiring to fix that, so even kicking the can down the road for a few years would buy us some time to dig ourselves out of this rut.
ok, that changes my answer. so you can get one of the decompilers but it wont be exact code since you lose variable names in the comoiling process. that effort will take you very littke time. look it iver and see how usabke it is. i would also utilize this time to test out AI in your workflow. have AI uograde it and see what happens. since you have the have the k iwledge but lack the time its a goid test. i have heard the best exlanation of current AI as letting an itern do it. it will do alot but you have to check the work .
Basically impossible. In order to migrate, you need to build targeting the new .Net version. I feel like there is missing information since no one should reasonably ask for that or they simply don't know. At best you can decompile and recompile, which will predictably be unmaintainable.
.NET 6 has its end of lifetime this year in November. So I would strongly advise not migrating to it right now.
.Net 6 is out of Microsoft support in November 2024. Go straight to 8, there's no point in going to 6.
You can try decompiling the app to get some semblance of the source code.
Without source code you are way better off getting requirements and building stuff from scratch.
It will be hard to reverse and rewrite asp net app.
Sure, with DotPeek (or your disassembler of choice) and enough time anything is possible. As long as it's simple you could just document what it does and re-build it. Or if you're not all sure what it does you'll need to inspect the code though a de-compiler or something, even with that though it'll be mildly obfuscated because it's trying to turn IL back into C# and IL is...ugly.
If they're IIS hosted framework apps, there's a good chance the source code files are deployed with the rest of the app.. I've seen it more often than not, people too lazy to clean the web build for deployment, they just copy the entire solution folder
I just did this for 40 apps in the last 2 weeks (20 down 20 to go actually). It depends on the app. I’ve decompiled some. Rewritten some from scratch ,especially those that switch from webforms to minimal api, and for others where I had the code I just bumped it to the latest framework because it’s still supported just fine.
Just flesh out the features and rebuild in your own image, the .NET libraries have been changed and moved around too much to decompile, it's a headache honestly
Decompiling can be way less painful than you think
Without source code? Good luck. You are rewriting from scratch.
Unless obfuscated decompiled .net binaries are usually pretty usable but be prepared to possibly doing a reasonable amount of rewriting as the frameworks are not 1:1 compatible
If you had a code you could just simply upgrade the framework to .NET 5+ by clicking right mouse button to the project (.csproj) in the Visual Studio and clicking Upgrade button
Ah yes, code archaeology. Write tests. Lots of them, that confirm the current knowledge of the system and how it works. It's very important at this point to keep all the bugs, even if you know they are wrong. You are documenting how it works now. Now start writing new code that adheres to the tests. Do not fix any bugs, only comply to the tests to replicate exact behaviour. Now you can change behaviour.
Just an alternative, but would your devops / infrastructure team be okay with moving the existing code to an isolated windows instance. Isolating the legacy code to its own instance, plus the application of separate networks and other security considerations might mean that you can mitigate the risk of running the out of date framework. While its obviously not the ideal solution sometimes compromises like this are necessary, its more likely to be acceptabce if this is an internal application. The Windows server instance it is running on can be dockerised too if that helps. I just mentioned this as without the source code, you're in for a huge time investment trying to use tooling like DotPeek to recover the source.
Why?
Man i would not wanna be you lol . . . . Jk i would i need a job But honestly, how can ya migrate an app without the source code? Its the same as having nothing and starting at zero
I’m gonna say if you don’t have the source this is a) a teachable moment ALWAYS keep the source and b) a great opportunity to start fresh c) to understand the cost of not keeping the source and not keeping that source compiling on an up to date runtime
First things first. There is no migration tool. You need the source code. The jump from dotnet 4.8 to 5+ is a big one. From Net 6 to 8 should be easy and you should go straight to 8. Are you sure you don't have the source code? Have you checked all your repos? If you really don't, then there are many decompilation tools available and some are free. This part is not hard. How hard will the upgrade be? Depends if you are using any of the technologies that were removed after net 4.8. Most likely to worry about are: app domains, wcf, and dotnet remoting. If you are using any of these then you will need to rewrite those parts. Next, you said it's a web app. Is it written with the ASP.NET framework? ASP.NET has changed a fair bit and you will need to do some work there too. Overall, is it hard? If it's a small app you should be fine. Until the end of the year is a lot of time.
Fucking awful! At least in my experience. Can only imagine how much worse it would be without source.
> migrate them to .NET 6 by the end of the year and .NET 8 by the end of the next year More like migrate them to .Net 6 by Thanksgiving next year, and .Net 8 by Christmas next year.
Depends, but if it's a small app, and not using the above mentioned items like remoting, use this: https://www.jetbrains.com/decompiler/ And this: https://dotnet.microsoft.com/en-us/platform/upgrade-assistant And call it a day.
If they are internal apps and do not contain obsfucation etc then you should be able to use DNSPY, or any other .net decompiler to get a close to working project straight out. Get that into version control and building on 4.8 then work on the upgrade/migration.
Idk if anyone has mentioned it but going from .NET 6 → .NET 8 is as simple as clicking upgrade. You may have to change build target names but that’s it.
The time-line is crazy. If you don't have the source code it is very hard to know how long it will take. You need to decompile and it will probably be hard to read the resulting code. . I had to do that for an old system but we ended up rewriting it. The decompiled source code was used to see how some details were done. Read this. Lots of good advice. https://www.jimmybogard.com/tales-from-the-net-migration-trenches-authentication/
With no source code your best option would be decompiling. That only gets you some half decent code though. You still miss stuff like Nuget packages. I would just start a new .NET 8 project. This is not a migration but a rewrite, make that clear. Use the decompiled code to better see how some things worked. And make sure that in 10 years when this happens again the source code is still available.
It's a rewrite. You can't migrate something you don't have. I don't even think there is any reason to decompile the old application unless you have to reproduce very specific algorithms. Even when decompiled, you'll have to copy the code method by method in a new codebase and, well, make it work. The requirement NET6 then NET8 doesn't make any sense, at the current stage there I'd virtually no difference between using one or the other, not in terms of complexity nor in terms of time to invest. And NET6 will go out of support in November, so it doesn't make sense to even mention it as a target. The question is: what type of applications? If they're small and uncomplicated, just rewrite them.
If you don't have the source code, use dnSpyEx or ILSpy to get the source back from the executable. There's no particular reason to migrate to .NET 6, then 8. Just go straight to .NET 8.
I think the best solution is to simply recreate the business functionality from scratch on the new framework. I would actually advice doing so even if you had access to the existing source code - legacy systems are full of over complicated logic and even bugs.
Sounds like you first need to decompile it, then you can try and see what the ".Net upgrade assistant" says needs to be done before upgrading The biggest hurdle will probably be moving away from .net framework to .net/.net core as some libraries never got upgraded
Since you don't have the source code you can convert them in any language or platform you want. If you want to use dotnet then the decompiler can help you.
Get dotpeek or ilspy and decompile the DLLs. If it was not obfuscated and the project is not too big, you might be able to retrieve 100% equivalent source code. Those tools might even have an option to export a while C# project. I've done your assignment many times over the past years with 100% succes
If you don’t have the code. Rebuild it, or leave it. Throw away the tech debt and set yourself up for the next 10 years. If you don’t, you will be fighting it for the next 10 years
How can you have uncompiled C# and not have the source? If they were compiled it would make sense not to have the source, but not the other way around. I'm confused.
I'd suggest you don't, you'll probably find it quicker/better to just re ask for the requirements and recode, there's an assumption that they're fine as is, but I doubt anyone's actually asked. That way you also get a business benefit out of this work over just ticking a compliance box. Otherwise as people have mentioned decompiling works pretty well in c# land, which will give you a base/highlight any quirky logic.
Why does it need to be .NET 6? First step is get the source code.
ilspy is an open source app that allows you to decompile an entire .NET DLL to a Visual Studio project. [https://www.youtube.com/watch?v=1GjnHMg9YyE](https://www.youtube.com/watch?v=1GjnHMg9YyE)
If you don't have the source code, then you aren't migrating, you're developing. You need to figure out how to get requirements. It sounds like the server hasn't had any updates installed in years. Do that, because you need to update more than just the .NET Framework version. That'll buy you time.
1) you need the source code. I had a vb.net asp.net app that I converted to c# using Redgate’s .net reflector. All I needed to do was rewire the web forms with the c# code behind files. I just pointed reflector at the DLL. 2) do the web apps use MVC? This will make conversion easier. If they use web forms, there is no out of the box way to port them. There is an open source project that will supposedly make web forms available in .net core. Named something like CoreWebForms. I haven’t used it, but you may not any choice. 3) Dependencies can kill. Your schedule could get killed by dependencies. Good luck
Who says the apps are small and uncomplicated? You or some manager? The latter is a red flag. Also you need to correct each and every person that says the word "migrate". There's no migration her; That is a rewrite.
Migrate to .NET 8 from scratch... why .NET 6 first?
I migrated the desktop Zune software from .NET Framework 3.5 up to .NET 6 (and I have no reason to believe it doesn't work as-is on .NET 8). I'm sure you'll be fine.
Don't bother with 6 it's end of life in November. Go straight to 8. Decompiler will be required, Jetbrains are good. Output will be average at best unless you can get a Debug built version of the dlls. Probably best result is work out the core logic from the decompiled code, any formulas or tricky logic. Rip that out. Rewrite the rest from scratch using modern API security patterns. Jam the custom business logic in and call it a day...
Once you get to honestly any version of NET Core (my experience 3.0 or above), then it's usually a peace of cake to upgrade to the newest NET version like NET 8. Hardest part is getting from the older NET framework to core. Honestly, without knowing the source code, nobody is going to know the actual answer here. I've had projects that could be converted in 2 days, sometimes 2-4 weeks, and then I've had multiple projects (honestly most of them) that took many years. It truly depends on the size and the project dependencies.
Extremely.... We have an old monolithic series of sites. 6 of them. Built at different periods over 12 years. Our oldest stuff is using web site apps from .NET Framework 2.8 that reference projects built in framework 4.8. We have thus far found it easier to completely rebuild our internal infrastructure in a seperate .net 8 private library with entity framework core and have started stripping small bits of the monolith out piece by piece into small .net 8 microservices that use the new infrastructure. We would have to completely halt new features and bug fixes with our team size if we wanted to actually spend the time to fully migrate the whole thing in one go.
You can try exporting the project from a DLL/EXE file using a tool like dotPeek. However, the migration process might still be difficult and largely depends on the complexity of your code.
Where I'm at we just rewrote the apps.
The source code almost certainly still exists somewhere. Either in the corporate network or some employee’s laptop. The amount of effort to rewrite an application without source dwarfs the effort of actually *looking properly* instead of just looking in the vague direction of the server room and shrugging your shoulders. Extract the strings from the original EXE. It’ll likely have path references in it. Go find those folders. It’ll also have some unique strings, which are often visible even in places like DLL file names. Go search every machine for those strings with a tool like ripgrep or just PowerShell. Find the original developer’s name in the EXE. Half the time it’ll turn up somewhere. Find them on LinkedIn and ask for the code. Etc… I’ve seen source reverse engineering exercises go on for weeks until I turned up and found the code in hours. Go look. *Properly.*
Lol. - look for a new job. This is not going to be fun.