In legacy Visual Studio projects that reference Eyeshot via NuGet, opening the Designer may sometimes fail with an “Invalid Developer License” error, even when the license is valid and correctly activated.
This behavior is the result of known Visual Studio design-time limitations and is not necessarily caused by a licensing issue. In practice, the error is often triggered by the way the designer initializes the project and its dependencies, especially after adding or updating NuGet packages.
Before attempting rebuilds or re-authentication, it is important to verify that Visual Studio is correctly configured to use the modern Windows Forms designer infrastructure.
1. Verify that the Windows Forms out-of-process designer is enabled
Recent versions of Visual Studio rely on the out-of-process Windows Forms designer to correctly load complex dependencies and licensed components at design time.
Make sure the following option is enabled:
Tools → Options → Environment → Preview Features
Enable “Use the preview Windows Forms out-of-process designer for .NET apps”
Restart Visual Studio after changing the setting
If this option is disabled, the designer may run in-process and fail to properly initialize Eyeshot, resulting in misleading license-related errors.
2. Rebuild the project after adding NuGet packages
For legacy projects, it is necessary to rebuild the project after adding NuGet packages before opening the designer. This is due to a known Visual Studio issue where design-time assemblies are not correctly resolved until a successful rebuild is performed. Typically, closing the form, rebuilding the project, and then reopening the form is sufficient.
3. Re-authenticate if needed
If the issue persists, ensure that Visual Studio is correctly authenticated:
Close Visual Studio
Run the authentication tool
Reopen Visual Studio and reload the solution
4. Close all Visual Studio instances (last resort)
As a final step, close all running Visual Studio instances before reopening the solution.
This helps clear stale design-time processes that may interfere with the designer initialization.
We will distinguish between two cases:
- Legacy projects using
packages.config - Legacy projects using
PackageReference
Case 1: Legacy Projects Using packages.config
When adding a NuGet package with dependencies in a project using packages.config, each dependency is managed as an individual package stored in the packages.config file. If even one of these packages is missing, it can cause issues, particularly at design-time.
Proposed Solution: Convert the project to use PackageReference, or even better, to an SDK-style project if possible.
How to convert from packages.config to PackageReference
- Right-click on the project in Solution Explorer and select
Migrate packages.config to PackageReference.... - Follow the prompts to complete the migration.
You can also set the default package management format for new projects in Visual Studio.
Go to Tools > NuGet Package Manager > General. Under Package Management, you can select either packages.config or PackageReference as the default format for new projects.
Case 2: Legacy Projects Using PackageReference
In legacy projects using PackageReference, dependencies are handled more efficiently. However, issues can still arise, especially if the project is not properly rebuilt after adding new packages.
Proposed Solution: Ensure that the project is rebuilt after adding or updating NuGet packages, or even better, convert it to an SDK-style project if possible.
Upgrade .NET Framework Applications
It is possible to perform two types of conversions for .NET Framework projects:
- Conversion to an SDK-style .NET project
- Conversion to an SDK-style project while maintaining .NET Framework as the target
To convert a .NET Framework project to .NET, you can use the Upgrade menu offered by Microsoft.
Note: In recent versions of Visual Studio, the Upgrade option may not be visible in the context menu by default. To enable it, go to Tools > Options > Projects and Solutions > Modernization and set Enable legacy Upgrade Assistant to True.
You will find 3 options:
- Upgrade project to a newer .NET version: this option will convert the .NET Framework project to .NET
- NuGet upgrades: this option will convert the project to use NuGet central package management
- Upgrade project features: this option will convert the legacy framework project to the new SDK-style.
Follow the prompts to update the project according to the chosen option.
Runtime assembly version conflicts (System.Text.Json and other BCL packages)
The cases above describe failures that happen at design-time. A separate problem can show up at runtime, on .NET Framework projects, when another library in the same application references a different servicing version of System.Text.Json than the one shipped with Eyeshot.
The error appears at runtime, the first time the conflicting assembly is loaded. The message looks like this:
Could not load file or assembly 'System.Text.Json, Version=10.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Why this happens
On .NET Framework, the out-of-band System.Text.Json package ships an assembly whose version follows the servicing build. Package 10.0.1 carries assembly version 10.0.0.1, package 10.0.8 carries assembly version 10.0.0.8, and so on. The runtime treats these as separate identities and loads only one of them, so two libraries that expect different servicing versions cannot both be satisfied without an explicit redirect. On .NET 6 and later the assembly is provided by the runtime and stays at 10.0.0.0, so the conflict does not appear there.
Eyeshot references the version of System.Text.Json required by its own dependencies. It does not need one specific servicing build. A redirect to the highest version present in the application satisfies it, because a higher servicing of the same major version is API compatible.
Preferred solution: let the build resolve and redirect
In an SDK-style project, or in a legacy project that uses PackageReference with AutoGenerateBindingRedirects set to true, NuGet promotes the highest referenced version and Visual Studio writes the binding redirect for you. Converting the project as described in the sections above is the cleanest fix, since it removes the need to edit configuration by hand.
Manual solution: add the binding redirect
If converting the project is not an option, add a binding redirect to the executable's app.config (or web.config). Point every reference to the highest assembly version actually deployed in the output folder, and confirm that the matching System.Text.Json.dll is the one sitting in that folder. If the redirect points to a version that is not there, the load still fails.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.8" newVersion="10.0.0.8" />
</dependentAssembly>
</assemblyBinding>
</runtime>Replace 10.0.0.8 with the assembly version of the copy you keep. You can read it from the load error itself, or from the assembly version reported for the DLL. Use the assembly version, not the NuGet package number and not the file version, since on .NET Framework these three can differ.
Note: The same redirect applies to any other assembly that produces this conflict. Add one
dependentAssemblyentry per assembly, and set each version to match the copy on disk.
Redirect the whole System.Text.Json dependency closure
Redirecting System.Text.Json on its own is often not enough. The first time the application serializes or deserializes, the full converter stack is loaded, which pulls in the rest of the package closure: System.Text.Encodings.Web, Microsoft.Bcl.AsyncInterfaces, System.IO.Pipelines, System.Memory, System.Buffers, System.Runtime.CompilerServices.Unsafe and System.Threading.Tasks.Extensions. If one of these is missing from a probed folder, or is redirected to a version that does not match the System.Text.Json servicing you settled on, that first deep call fails even though shallower usage elsewhere in the application never touches the missing piece.
Deploy the complete closure in a probed folder and redirect every assembly in it to one consistent version. A common oversight is leaving Microsoft.Bcl.AsyncInterfaces or System.IO.Pipelines at an older version while pushing System.Text.Json higher. Keep the whole set aligned.
Additional Tips
- Rebuild Regularly: Always rebuild your project after adding or updating NuGet packages to avoid design-time issues.
- Monitor Dependencies: Keep an eye on your NuGet package dependencies and update them regularly to avoid conflicts and missing packages.
- Use Visual Studio Tools: Utilize Visual Studio's built-in tools for managing and migrating NuGet packages to streamline the process.
-
Resolve Version Conflicts: When another library pulls a different servicing version of
System.Text.Json, redirect to the highest version present rather than downgrading any package.
For a comprehensive guide on handling Eyeshot NuGet packages, please refer to the general article here.
Comments
Thank You
I Problem Solved!
Please sign in to leave a comment.