Migration Guide: .Net Framework to AutoCAD 2025/.NET 8.0

[_gile]

I tried to write a basic step by step migration guide in French. If anyone has the courage to translate it into proper English (I can provide the .docx file if needed)...

[Jeff_M]

I have created an English translation of the migration guide @_gile posted.

[Ed__Jobe]

Thanks @_gile and @Jeff_M 

[kerry_w_brown]

Thanks Gilles,

Thanks Jeff,

@Jeff_M 

I think the Launch Profiles => Command Line Arguments should be 

/nologo /b "start.scr"

Regards,

[Jeff_M]

@kerry_w_brown good catch!

[Alfred.NESWADBA]

Hi,

thank you both @_gile & @Jeff_M !

Let me add one experience I had, referring to the list of files to be used for conversion:

I had a situation where I selected a VBProj-file to be converted and the converter listed all VB-files inside the folder, and not just the ones, that were part of the VB-project. Letting all files checked (in the list of files, where checkboxes are shown) will result in having all the files added to the new/converted project.

I had not done a lot with the converter, but that happened during my tests twice, so not just one time and one project.

Maybe that with C# that works better. But be careful about that.

- alfred -

[Alfred.NESWADBA]

Hi,

may I ask a question regarding the output folder?

Now it adds automatically "net8.0-windows" as subfolder to the destination folder I set in the project settings.

Has anyone found an option to not do that? Our apps-output-folders are quite strong structured in directories per AutoCAD version, having now subfolders would kill this structure (which was working really well since beginning of AutoCAD with .NET Framework)

- alfred -

[kerry_w_brown]

@Alfred.NESWADBA 

Try :

https://learn.microsoft.com/en-us/visualstudio/ide/how-to-change-the-build-output-directory?view=vs-...

ADDED:

perhaps this would suit you too

https://learn.microsoft.com/en-us/visualstudio/ide/specifying-custom-build-events-in-visual-studio?v...

Regards,

[_gile]

@Alfred.NESWADBA 

You can add this PropertyGroup to the .csproj/SDK file.

<PropertyGroup>
	<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
	<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
</PropertyGroup>

See this topic.

[kerry_w_brown]

@Alfred.NESWADBA 

As well as the link Gilles mentioned, perhaps have a look here too :

https://learn.microsoft.com/en-us/visualstudio/ide/specifying-custom-build-events-in-visual-studio?v...

Regards,

[ziggy63]

Hi Gilles,

Thank you very much for the guide. I tried to follow your instructions but the upgrade of all my vb projects failed, with the following error message:

Does this message mean anything to you? What am I doing wrong? Has anybody else encountered this error?

Thank you in advance,

George

[Alfred.NESWADBA]

Hi,

@_gile 

>>You can add this PropertyGroup to the .csproj/SDK file.

Wow, searched for that, but was not able to find this link.

Thank you so much!

- alfred -

[_gile]

---

@ziggy63 wrote:

Hi Gilles,

Thank you very much for the guide. I tried to follow your instructions but the upgrade of all my vb projects failed, with the following error message:

Does this message mean anything to you? What am I doing wrong? Has anybody else encountered this error?

Thank you in advance,

George

---

Never seen that message before. It seems to be an error with the Upgrade Assistant.

[ziggy63]

So, I seem to be the only person on planet Earth who cannot upgrade a VB project from .NET Framework to .NET, using Microsoft's own tools! Now, this is interesting...

[Alfred.NESWADBA]

Hi,

are you sure that you have installed the .NET 8.0 SDK?

I have had messages similar to yours (not sure if that really were the same), before I installed this SDK (I just was looking into the VS2022 installed parts (tools and features) and have seen ".NET 8.0 Runtime (Long Term Support)" aas well as ".NET SDK" and thought, that should be enough. Later I recognized that this is not all that is needed and installed the "real" .NET 8.0 SDK from here: >>>click<<< for downloading .NET 8.0 SDK (v8.0.203) - Windows x64 Installer!

HTH, - alfred -

[ziggy63]

Hi Alfred,

I reinstalled the SDK, using the link you sent me, but the problem persists.

Thank you anyway.

[_gile]

---

@ziggy63 wrote:

So, I seem to be the only person on planet Earth who cannot upgrade a VB project from .NET Framework to .NET, using Microsoft's own tools! Now, this is interesting...

---

No, you're not alone:

https://stackoverflow.com/questions/77932310/net-upgrade-assistant-error-when-converting-csproj-file...

https://stackoverflow.com/questions/78141705/net-upgrade-assistant-fails-on-converting-project-to-sd...

[ntclmain]

Thank Gile.

*

Relating the Migration guide, I've found some pieces of information from Autodesk Civil 3D 2025:

Known Issues in Civil 3D .NET Core Development

https://help.autodesk.com/view/CIV3D/2025/ENU/?guid=GUID-B50CC834-E202-48FE-9C64-526EF9828535

".... 

Plugin fails to load due to the lack of a framework reference to Microsoft.AspNetCore.App
Civil 3D does not rely on Microsoft.AspNetCore.App, so it has not added this reference. If your plugin has a dependency on it, it may prevent the plugin from running.

Solution: Edit the acdbmgd.runtimeconfig.json file located in the Civil 3D root folder by adding a reference to Microsoft.AspNetCore.App. If you are using a script or installer to add it, incorporate logic to check whether the user or other plugins have already included it before adding it to avoid duplication. Also, ensure that the desired version has been installed by Civil 3D using the "dotnet --list-runtimes" command. Otherwise, you may consider including the framework installer within your plugin installer. ..."

---

About Civil 3D .NET Core Development

https://help.autodesk.com/view/CIV3D/2025/ENU/?guid=GUID-E6657034-71E5-4753-8AFD-139DC612B86D

.....As per claims such as https://github.com/dotnet/runtime/issues/68041, .NET framework DLLs could continue to work within .NET Core runtime as long as they don't use any API exclusive to .NET Framework, However, you should conduct thorough testing on your own to ensure it functions properly within the .NET Core environment if you choose to stay with .NET framework." ....

---

*

I wonder why those information does not appear in AutoCAD 2025 ".NET migration guide"

https://help.autodesk.com/view/OARX/2025/ENU/?guid=OARX-ManagedRefGuide-_NET_Migration_Guide

*

Previously, I've tested my .NET Framework 4.8  libraries in AutoCAD 2025 (by mistake).  My project is multi targets and I load the wrong file.  It works so smoothly that I didn't find that the wrong version is loaded, until I found commands under   #If NET5_0_OR_GREATER   directive do not work as expected.

However, another guy in feedback forum (Alexandr Chernishev) reported that his plugin could launch, work, then the error “SQLClient file not found” popped up.

[norman.yuan]

Thanks for the efforts and contributions from @_gile and @Jeff_M. It is a big help.

I thought it might be even better if the guide includes some general suggestions on whether to migrate or not, because many AutoCAD programmers coming to here are not fulltime or career-programmers, some may be quite new to AutoCAD programming, so the evolving history of .NET technologies and AutoCAD .NET API could be rather confusing. It is certain that Autodesk's very poor .NET Migration Guide documentation does not help much at all.

Here are some of my thoughts:

1. Many existing .NET plugins based on .NET Framework (4.x) should work with AutoCAD 2025 just as they work with prior AutoCAD versions. Of course, it depends what the .NET Plugins do, so, they have to be fully tested. But it is important to know: the common sense of "if it aren't broken, do not fix it" should be paly a big role in making migration decision;

2. Not all projects need to be migrated to .NET 8, if the plugin is meant for multiple versions of AutoCAD (which would be true to most existing projects since AutoCAD 2025 is just out).

• For bug fixing of existing plugins, if it works OK in AutoCAD 2025, we can still fix/debug it with existing .NET 4.x project and compile it, so it remains as single set of code that works with older AutoCAD version and Acad2025; It is also possible to enhance the plugin with new feature and still working with older Acad and Acad2025.
• If the existing plugin is indeed broken with AutoCAD 2025, then the migrate to .NET 8 is necessary, if the plugin needs to run with Acad2025. But in this case, in order to support older AutoCAD, 2 sets of code are in .NET 4.x project and .NET 8 project respectively. 
• For the project migrated to .NET 8, or a new project created in .NET 8, it will not run with older AutoCAD version prior to Acad2025.

So, I think it would quite important to realize that at this stage (that is, majority of AutoCAD users will still use AutoCAD 2024 or older for quite a while) that continuing to maintain existing plugins with .NET 4.8 would last for foreseeable period, as long as the existing plugins work ok in older AutoCAD versions and AutoCAD 2025. Only do the migration if the target AutoCAD version is 2025 or newer.

[SENL1362]

May i add: You also need to upgrade to .NET Core if you want to use the new features of C# 8 and higher.