VB Project/Solution Framework upgrade to SDK for Revit 2025

[GaryOrrMBI]

Ok... I've read all of the posts regarding upgrading, I have applied everything that my limited experience allows me to understand (Been doing this for years, but on a limited basis as writing code isn't even in my job description these days and I can barely decipher all of the C# examples since I'm not bilingual and my native language is VB).

So far I have managed, through days of trial and error, to port one of my solutions (with 3 Projects) and have slowly whittled away the errors and warnings. My WinForms dialogs were a real bear but I finally managed to delete enough tags in the VBproj files to get them working (creating a new WinForms solution and project from scratch and doing some comparisons helped with that as it didn't have all the extra gobbledygook in it).

Finally upgraded successfully with one exception:

Warning MSB3277 Found conflicts between different versions of "WindowsBase" that could not be resolved.

I've updated to all of the latest (which I'm beginning to believe might be my issue)

I'm working in

Visual Studio Community 2022 Version 17.9.6

With 

dotnet SDK 8.0.204

The expanded form of the warning looks like this:

Warning MSB3277 Found conflicts between different versions of "WindowsBase" that could not be resolved.
There was a conflict between "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "WindowsBase, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
"WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "WindowsBase, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not.
References which depend on "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\WindowsBase.dll].
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\WindowsBase.dll
Project file item includes which caused reference "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\WindowsBase.dll".
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref/net8.0/WindowsBase.dll
References which depend on or have been unified to "WindowsBase, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [].
C:\Program Files\Autodesk\Revit 2025\RevitAPI.dll
Project file item includes which caused reference "C:\Program Files\Autodesk\Revit 2025\RevitAPI.dll".
RevitAPI
RevitAPIUI
C:\Program Files\Autodesk\Revit 2025\RevitAPIUI.dll
Project file item includes which caused reference "C:\Program Files\Autodesk\Revit 2025\RevitAPIUI.dll".
RevitAPIUI
C:\Program Files\Autodesk\Revit 2025\AdskRcManaged.dll
Project file item includes which caused reference "C:\Program Files\Autodesk\Revit 2025\AdskRcManaged.dll".
RevitAPI
RevitAPIUI

...

Those last four lines repeat about 50 times with the only change being the name of the dll (most listing both RevitAPI and RevitAPIUI but several just listing RevitAPIUI).

I get this warning on both the ported/upgraded solution/projects as well as the solution/project that I started from scratch.

Has anyone seen this warning and/or know a solution for resolving the conflict between the Revit API references and the newer native .Net references?

Thanks in advance for any assistance,

-Gary

[jeremy_tammik · Accepted solution]

I am not fond of VB, and never was, but I sympathise.

Congratulations on making progress, though, and very sorry this is such a hassle for you.

First, warnings can be ignored. They do no harm. Of course, it is nicer to eliminate them.

Actually, the very warning MSB3277 that you mention is also listed in the official Revit API .NET 8 migration guide:

• https://thebuildingcoder.typepad.com/blog/2024/04/migrating-from-net-48-to-net-core-8.html

Common Issues

Here are some common issues you may encounter when upgrading to .NET 8:

  
Build Warning MSB3277

When building code that references RevitAPI or RevitUIAPI, you will see the build warning MSB3277. To fix this, add a reference to the Windows Desktop framework: <FrameworkReference Include="Microsoft.WindowsDesktop.App"/>

Wishing you much success and a happy peaceful weekend.

[GaryOrrMBI · Accepted solution]

Thank you @jeremy_tammik.

I did see that reference, but it doesn't say where to put it or what container node it required (I had correctly assumed that I could use the vbproj file, since it's the same xml as the csproj file) and tried adding it to the(a) <PropertyGroup> node at which VS completely wigged out and said that an invalid call forced VS to unload the project...

I then spent a day following link after link in the MS documents trying to figure it out as well...

I had also tried using the Add Reference function to see if I could load it that way:

But I couldn't find it as an available loadable reference.

So, with your prompting I tried again...  This time I used VS intellicode to help me work it out (Create a node, check to see if that node contained the <FrameworkReference> property, repeat until I found the correct one).

I think this little additional piece of information would go a long way in helping people like myself 🙂

  <ItemGroup>
    <FrameworkReference Include="Microsoft.WindowsDesktop.App" />
  </ItemGroup>

 and now I have: 

along with a warning free build.

Now perhaps I'll tackle the big toolset...

As for the C# vs VB... I know that I'm going to have to learn C# at some point since everyone else has already done so but, as to preference, I like the way that VB statements and functions "explain themselves" as you go, it makes following what you're reading much easier:

Give dimension to a variable:

Dim thisVar As ThatObject - someValue

Functions follow the same repeatable structure and are clearly defined with a start and end:

If this Then

 do this

ElseIf this other Then

 do this other thing

Else

 everything else failed so do this

End If

Se;ect Case fromThisValue

Case matchThis

 do this

Case matchThisOther

 do this

End Select

But mostly just because it's what I know from the history of: VisualLisp wasn't doing enough but VBA had the answer to that and was in everything at the time I was learning (AutoCAD, AutoCAD verticals, Excel, Access, etc.)

That made for an easy and natural transition to VB with free MS tools and eventually into today's Visual Studio.

Thank you again for confirming this requirement and pushing me to try again to see what I missed/mis-understood.

-Gary

[GaryOrrMBI]

Adding another note to this...

I'm not sure what the upgrade process does differently from one project to the next but, whatever it is it isn't consistent.

On the very next project the framework references came in differently and the FramewrokReference tag that the previous project required caused a warning and I had errors due to a missing reference that had been automatically added to the other projects when I set the target to windows using 

<TargetFramework>net8.0-windows</TargetFramework>

So I had to do this to make it all come together: 

  <ItemGroup>
    <!--<FrameworkReference Include="Microsoft.WindowsDesktop.App" />-->
    <FrameworkReference Include="Microsoft.WindowsDesktop.App.WindowsForms" />
  </ItemGroup>

-G

[RPTHOMAS108]

Also found this works:

 <UseWindowsForms>true</UseWindowsForms>

This just highlights the way things have gone a bit backwards i.e. System.Drawing 4.0 instead of 8.0??? So you add additional things to the point it basically becomes .NetFramework again anyway. Yet they still can't open Revit on their mac or their phone and were never aiming to.

Think they should have got rid of application macros not the document ones. Document macros offered the ability to transmit functionality across offices on a project specific level i.e. with the project files not as some separate things such as dynamo script etc. Application macros are just another way of doing the same thing as VS or pyRevit or half a dozen other things similar.

[GaryOrrMBI]

UseWindowsForms was the first tag I used (thanks to a lot of reading in the API help and the posts made here by some people that, unlike myself, actually know what they're doing)...

But... it didn't do the complete job.
I had to delete extra lines/tags and add a few additional lines/tags...
and scratch my head, and cuss, and try deleting some more and try adding others...
then cuss some more...
then scratch my head some more...
But I do now have everything compiling properly for two solutions with a total of four projects...

Each project ended up requiring a slightly different combination to get them working...
I only have two more solutions to go, yay me 🙂

-G

[RPTHOMAS108]

Yes certain things are fixed into the Frameworks aren't they (more than there was with .NetFramework) so you have to review those already included reference versions and if you've referenced them separately historically then you have to take those out. In this example there was newer references used in the Revit API dlls due to options they compiled those with. So the baseline references used in .net 8 were older in version than the ones included with windows desktop option. So in a lot of cases may be easier starting over with the project file references and adding references back as you see the related missing references errors for those.

So as an example:
Microsoft.NetCore.App
contains
Microsoft.VisualBasic 10.0.0.0

but
Microsoft.WindowsDesktop.App
contains
Microsoft.VisualBasic 10.1.0.0

So if you don't include the desktop option but include a reference that does i.e. RevitAPI.dll it tells you it is going to ignore 10.1.0.0 (since that is not added in your project). This would be a problem I suspect if you used a call from 10.0.0.0 that didn't exist anymore in 10.1.0.0 (since Revit is likely to be loading 10.1.0.0 not 10.0.0.0, first come first served).

So isn't really VB specific that is just one of the affected assemblies that is part of Microsoft.NetCore.App but there are similar warnings for System.Drawing etc. You only encounter them if you use them in code so different projects will have same problem with different things.

[GaryOrrMBI]

@RPTHOMAS108 

Good advice on the start a project from scratch note. Creating a project(s) from scratch (in a solution(s) created from scratch) for the different types of projects I had to deal with (WinForms project, WPF project, Console App, standalone executable [the last two not related to the Revit API, just noting them], etc) was one of the methods that helped me find what was actually required and what might be able to be safely removed. I would recommend that for anyone making the transition from Framework to SDK.

I also found a few repeated tags that were added to <PropertyGroup> nodes by the upgrade tool whose removal helped greatly:

    <!--<OutputType>Library</OutputType>-->
    <!--<MyType>Windows</MyType>-->
    <!--<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>-->
    <!--<GenerateAssemblyInfo>false</GenerateAssemblyInfo>-->

 The GenerateAssemblyInfo and ImportWindowsDesktopTargets seemed like they would belong yet they were causing issues that seemed contra-indicative to what they would seem to be adding to the whole...

Oh well, if it was easy it wouldn't be any fun right?

ReallyBigGrin

Happy Coding,

-G

[choshQT24J]

"It's a shame that Autodesk doesn't release a complete walkthrough without any compilation warnings even that revit 2026 is going to release .