NORMA Support for VS2026

[j0hnnymiller]

I've installed NORMA in VS2026 18.8.2. when I open a .orm model VS opens it as a text file, not a model.

I've installed and uninstalled VS and NORMA several times with no success.

Any help would be greatly appreciated.

jMM

[jMM-at-CODEGroup]

Here is the message I get when I open a .orm file from file explorer:

The 'ORM Solutions Natural Object-Role Modeling Architect Package' package did not load correctly.

The problem may have been caused by a configuration change or by the installation of another extension. You can get more information by examining the file 'C:\Users\JohnM\AppData\Roaming\Microsoft\VisualStudio\18.0_64cdcdd7\ActivityLog.xml'.

Restarting Visual Studio could help resolve this issue.

[jMM-at-CODEGroup]

ActivityLog.xml
ActivityLog.Setup.xml

[mcurland]

Thank you for the log. I think this gives me a starting fix on what is going on, namely that NORMA could not load Microsoft.VisualStudio.Modeling.Sdk.Shell, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.

Here is what I think is happening:

1. VS2026 decided to be 'helpful' to extension developers by keep VS2026 installations in the 17.x range, which is the same as VS2022. In fact, Marketplace won't even let you upload a vsix in the 18.x range. This hasn't helped anything because now I need to either support two targets in the same assembly or to display different package titles in Marketplace (currently all package titles are the same but limited to one version so VS filters out the out-of-range versions and you only see one NORMA).
2. There are subtle differences between versions. Examples: the environment DTE object (used to open some dialogs) is retrieved from the running object table with a specific version; version 2026 blew up the XML menu (affects per user install) so the menu response had to be completely reworked to handle injecting a menu item at multiple locations. The code looks something like a polyfill file in JavaScript.
3. This looks like another issue I missed. At some point, there were some VS installations that did not reliably install 4 of the modeling sdk assemblies required to run NORMA. I hadn't discovered the Prerequisite lists at the time (2018 timeframe) so I just fixed the problem by copying the assemblies I needed as backup. If these are installed normally it uses the VS copies, otherwise the backup is found in the NORMA install directory and life goes on.

So, what is the theory here? The prerequisites are not in the VS installation, so the tool is falling back on my fallback hack--which have version 17, not 18, because this is actually the VS2022 build (because Microsoft won't let install a VS2026-specific build). The likely cause of failure is that these assemblies rely on other version-specific assemblies installed in the tool, and of course these simply aren't there because you're in the wrong VS version.

I think I can fix this by adding a Prerequisite tag for Microsoft.VisualStudio.Component.DslTools in my extension manifest file, but I'll need to strip one of my VS installs down to bare minimum to test this. In the mean time, if you turn on the 'Visual Studio Extension Development' workflow (near the bottom under Other Toolsets in the main VS installer page (not the Extensions page)) then NORMA should start loading correctly.

[mcurland]

One more: check the optional 'Modeling SDK' box that you are offered with 'Visual Studio Extension development'.

In the vsix manifest I believe I can just select the component, but you aren't offered that in the UI.

[jMM-at-CODEGroup]

Thanks for the help. NORMA now tries to load the model, but I'm seeing this error now:

Cannot load 'C:\git\zeus\zeus.academia.3b.github\models\orm\academia.orm': Error HRESULT E_FAIL has been returned from a call to a COM component.

I've attached the installation log from when I installed Extension Development workload.

dd_VSIXInstaller_20260807145713_79e0.log

[mcurland]

I'm going to rebuild and post updated vsix files without the installer hack. Trying to replicate the exact installation that is causing this is providing to be fruitless on this side. Just let me do a normal rebuild this and I'll see where this lands before digging into individual files.

PS The digital signing is the slow part, it takes forever (like 90% of build time) since VS switched their signing tool and sectigo switched to dongle signing tokens, so this will probably take 45 minutes or so to post.

[mcurland]

1.0.3051.4 is uploaded on Marketplace. I made a couple of adjustments to the first approach:

1. The DSLTools component is added for all of the admin (NOT per-user) installs without the system files in the .vsix file. This is harmless because there are no user side effects to adding the component when you are already under ACL setup permissions.1. In VS2026 and VS2022 1. I could not actually get the ManagedDesktop (.NET Desktop Development work area, which has been a NORMA prerequisite for a long time) to be checked without also having these assemblies installed (they are required for TextTemplating, which cannot be unchecked from the core managed desktop component). Given that adding a new VS prerequisite makes the per-user install an admin install (to add the prerequisite, which is integrated with core VS), I just removed the files so the backup files so there no chance of loading them. You didn't indicate if you were an admin or per-user installation, so these are now slightly different. If this happens still under per-user settings I need to know the exact VS configuration (from the VS installer) that you're running under.
2. The older installs (VS2017 and VS2019) did not change for per-user, so the backup files are still included. This works fine because we know the target visual studio version.

So, please let me know if this works for you. The update should remove the old local files, but to be extra sure you can uninstall NORMA first, then reinstall after shutting VS down. You should also be able to turn off the extension development file block.

I'm assuming the other two people in this thread are the same, just under a work vs. personal login. Is that correct?

Beyond this fix I'd need some more detailed installation and especially debug info from your machine.

[jMM-at-CODEGroup]

The new build worked and didn't work. With the normal version I'm getting the same error. I tried the Per User version for the first time, and it worked!

I'm assuming the other two people in this thread are the same, just under a work vs. personal login. Is that correct? Yes

Let me know if there is anything I can provide to help you troubleshoot the normal installation.

[mcurland]

OK, that's somewhat good news but is not what I was expecting (but at least you can open your file). You mean you're still getting the error with the version 17.0 Microsoft.VisualStudio.Modeling.Sdk.Shell assembly, or the later error different error? BTW, attaching another Visual Studio instance as a debugger before loading will often get you a better error report.

Here's a wild guess: when the version was updated the same directory was used, but the 4 Microsoft.VisualStudio.Modeling.Sdk*.dll files were not removed. To find the installation directory under admin install:

1. Open your start menu and look for 'Developer' to find the standard VS developer command prompt and open it.
2. cd Common7\IDE\Extensions Note that the subdirectories here have generated names (except for a handful of Microsoft ones).
3. To find the NORMA install directory, dir /s ORMDesigner.pkgdef and note the directory.
   1. If you don't get a hit, look for the Microsoft.VisualStudio.Modeling.Sdk.Shell.dll file instead.
4. Change to that directory and see if there are any Microsoft.* assemblies in there. If so, you should delete them.
5. They likely won't delete easily because you don't have permissions. First 'start .' from the command prompt, then delete from the Windows explorer shell, which will provide the ACL prompt (make sure VS isn't running if it says the file is in use).

The assemblies are definitely not in either version of the posted installer package anymore.

Thank you for working through this with me.. VS seems like a stable platform to install on, but the amount of variation with all of the 'tools and features' options and the even wider world of extensions does cause an occasional problem. This forced multi-targeting (running VS2022 extensions on VS2026) has just exacerbated the usual upgrade pain points (in ways that are only obvious after they're discovered).