Closed lukekaalim closed 8 months ago
TODO
/home/lukekaalim/Projects/MDK-SE/Source/MDKBuild/MDKBuild.csproj : warning NU1701: Package 'Microsoft.CodeAnalysis.Workspaces.MSBuild 4.5.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project. [/home/lukekaalim/Projects/MDK-SE/Source/MDKCommandLine/MDKCommandLine.csproj]
means
net48;net7.0
.Pending question:
MDKProjectProperties
a mixin? Does this integrate in a special way?MDKProjectProperties: I don't remember, it's been too long. Something about the analyzer vs mdk. There was some reason why I wanted it to be embedded rather than being its own DLL. No sample projects.
I just realized a secondary problem. Since I'm not gonna be working on MDK2 any time soon (which is a completely separate project not in this github btw) I also tried again to convert this project to support VS'22 with some limited success. There's a significant amount of change required in the VS addin project for this to work.
VS2022-conversion branch.
It is not complete, but it must be taken into account as it's far more likely to be the next big release than MDK2 is.
Hm. I wonder if perhaps you wouldn't be better served working with that as your base, since you're not using Visual Studio yourself at all. I have to somehow get a VS'22 compatible version out sooner rather than later.
In terms of additional support for VS22, would that include dropping support for VS19, or would you be maintaining two simultaneous extensions?
2019 support will be dropped.
I am very close to getting the '22 version working now (you actually got me working on it right now, which wouldn't have happened if you hadn't started this conversation :D )
Very close, as in, successful. My wondering above just became a requirement. I won't merge the branch to master just yet, I need to run a preview installer for a while first, but there is no longer any question that this will become the main version.
I truly have done some horrible things to this nice codebase to get this working, but my single-action CLI mode now works.
I'll rebase this branch onto VS2022-conversion
and pick up the Malware's Dev Kit - 22.sln
solution and make sure everything wires together there, and then I'll kick open windows and fix the million little things I broke along the way.
There was really only one mostly cosmetic refactor that I touched in MDK.Build: the BuildModule is kinda coded to attack a whole solution at once, since that's what you're operating on in Visual Studio.
I've moved some orchestration code into a crude ProjectBuilder, which has a smaller scope to just building a single project, since that's all I needed for the CLI. I need to refactor BuildModule to just sub out to ProjectBuilder as well.
I'm also certain I've broken where the script gets output since I kept touching the path generating expression, so that needs fixing too to avoid breaking compatibility with all the existing projects.
It's not a separate solution. That's some remnant of an older attempt to convert. Sorry :P
Oh lolol, so in VS2022-conversion
the main Malware's Dev Kit.sln
should be the one I use?
Yep :D
I feel a little stupid - VSCode's C# extension has like a mono mode and a netcore mode, and I keep forgetting to switch between the two when I work on the extension versus the command line, which causes me to hallucinate a bunch of bugs that I spent too long working on.
Okay, I've cleaned up the code - everything works on my instance of VS2022, but take that with a grain of salt. Still missing is me unbreaking all the error messages since I haven't looked up yet how these string resource files work, but it should be fine if you want to to take a broad look at it.
Summary of changes so far (from git commit message):
Move Build directory into separate project
- Also, the ProjectSettings Mixin is now implemented in MDK.Build
- MDKServices now depends on MDK Build, and not on ProjectSettings Mixin
- Some Legacy ProjectProperties partial classes have been deleted since I dont think a partial class can spread across assemblies (though let me know if its important to keep)
- Refactored MDK (core) to use MDK.Build's SolutionB uilder instead of BuildModule
- Error resource text is still messed up
Hey. I'm planning to merge the '22 branch to the main one tomorrow and release the '22 version as the primary. I wonder if this branch then can simply be re-targeted, or how we solve that... worst case scenario I can keep this branch around until you're done, merge your branch here first, and then merge once again into master...
I can just retarget it. Since this one is branched off 22, the once 22 is in main then I should just be able to retarget to main without issues. While to code is good to review, there are one or two more small things I still need to patch up before merging, so I don't want to hold you back from the main release.
And double checking both pipelines (though the CLI doesn't yet have a script manager equivalent, so just copy pasting for now)
FYI the branch has now been merged and you should retarget back to master.
Hm. It seems this branch is no longer a draft. Is it ready for review? I thought you said you had some more stuff you needed to do?
Oh, sorry, I should have been more clear lol - I've been slowly ticking off things in my todo list at the top, and I'm all done with a "minimum" set of features. I didn't want to bloat this PR more than it is already, since it includes a small refactor + large movement of code.
But yeah, it's totally ready for review! Let me know what you think.
Please don't delete any files.
Also; suggestion: How about shortening it to mdkc
?
Hm. We have some out-of-place namespaces here... Did you move the comment strippers?
(edit: No you didn't, I did that and apparently didn't repair the namespaces. Gonna have to remember to fix that then.)
Obviously I reserve the right to rewrite the command line program to match my own coding style at some point in the future (maybe, probably not), but other than that and the showstopper above which I'm sure you can fix easily enough, I don't think I see any problems here.
I would also like to request that you type up a tutorial markdown in the style of my wikis, to show how to use this program.
Please don't delete any files.
Is that specifically about BuildModule (or did I accidentally delete something else)? I needed to shift around some of the logic to it get it to work, so I spread to the two new files: SolutionBuilder and ProjectBuilder. I can revert the deletion and bring it back, but I though it might be better practice to have a single implementation of the build orchestrator, since I also retargeted the previous references to point to it (I can undo that as well, and have the CLI and Extension have divergent ways of invoking the build process to keep these projects more isolated).
(Edit) Actually, is this about the legacy partial classes from MDKProjectProperties? Sorry, I forgot I removed them - since the mixin previously applied to MDK.Services but has now been retargeted to MDK.Build specifically, I think it makes sense to move those files into MDK.Build since I don't think the project will compile otherwise.
Also; suggestion: How about shortening it to mdkc?
Hah, sounds fine.
I would also like to request that you type up a tutorial markdown in the style of my wikis, to show how to use this program.
That's a great idea actually. I'll get started on that.
(edit: No you didn't, I did that and apparently didn't repair the namespaces. Gonna have to remember to fix that then.)
I'm not sure specifically what that refers to - let me know if theres anything in this branch you want me to change, but it sounds like that was something that happened on master?
No, the things you have moved around is fine as far as I can see. You've deleted some legacy files, see the change list.On May 12, 2023 09:25, Luke Kaalim @.***> wrote:
Please don't delete any files.
Is that specifically about BuildModule (or did I accidentally delete something else)? I needed to shift around some of the logic to it get it to work, so I spread to the two new files: SolutionBuilder and ProjectBuilder. I can revert the deletion and bring it back, but I though it might be better practice to have a single implementation of the build orchestrator, since I also retargeted the previous references to point to it (I can undo that as well, and have the CLI and Extension have divergent ways of invoking the build process to keep these projects more isolated).
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Hi. What is happening with this?
Oh, I see. I didn't get a notification because you edited your post.
Moving files is fine, as long as any relevant logic is maintained, but right now I can't seem to find them at all.
since the mixin previously applied to MDK.Services but has now been retargeted to MDK.Build specifically, I think it makes sense to move those files into MDK.Build since I don't think the project will compile otherwise. What do you mean?
Don't assume this is the only project using the mixin.
Lack of responses to my queries, as well as the situation with Microsoft vs MDK1 meaning MDK2 is now in full development, means this will be closed and not merged.
Related to #195
This pull request represents a very work in progress sketch of this functionality, though as it may be touching involved settings and project layout it might be useful to see how it goes (and if there's anything egregiously awful that I should attempt differently).
Goals: