Remove support for legacy csproj format

[OsirisTerje]

The legacy csproj format, using the package.config files and thus the old project system can not handle transitive dependencies. This is a blocker for changes we're doing in V4.

The current plan is now to release V4 with supporting the new SDK based csproj files only.

The legacy will be supported by the 3.X series of adapters, but they will only see small simple bug fixes and updates whenever an update to Visual Studio that breaks the adapter happens.

We don't see any reason why you would update the adapter, and not update your csproj files, in particular since these are "only" test projects.

What do people think of this?
Will this bring too much hardship to developers?

[rprouse]

I'd support the change especially if it is causing problems. You will get complaints and bugs filed though. Is there a way that you can detect the old format and display a warning?

[OsirisTerje]

I possibly could catch the exception, and then check if requested correct dll's are present or not, and deduct from that. So yes, it could work.

[OsirisTerje]

@rprouse @ChrisMaddock Well, the error happens before the adapter is involved, and the testhost is not able to load from the engine.

TpTrace Warning: 0 : 27928, 3, 2021/01/30, 18:04:28.274, 6341511073038, testhost.x86.exe, TestPluginDiscoverer: Failed to get types from assembly 'NUnit3.TestAdapter, Version=4.0.0.0, Culture=neutral, PublicKeyToken=4cb40d35494691ac'.  Skipping test extension scan for this assembly.  Error: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.RuntimeModule.GetTypes()
   at System.Reflection.Assembly.GetTypes()
   at Microsoft.VisualStudio.TestPlatform.Common.ExtensionFramework.TestPluginDiscoverer.GetTestExtensionsFromAssembly[TPluginInfo,TExtension](Assembly assembly, Dictionary`2 pluginInfos)
TpTrace Warning: 0 : 27928, 3, 2021/01/30, 18:04:28.275, 6341511086023, testhost.x86.exe, LoaderExceptions: System.IO.FileNotFoundException: Could not load file or assembly 'nunit.engine.api, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb' or one of its dependencies. The system cannot find the file specified.
File name: 'nunit.engine.api, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb' ---> System.IO.FileNotFoundException: Could not load file or assembly 'nunit.engine.api, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb' or one of its dependencies. The system cannot find the file specified.
File name: 'nunit.engine.api, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb'
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Microsoft.VisualStudio.TestPlatform.Common.ExtensionFramework.TestPluginCache.CurrentDomainAssemblyResolve(Object sender, AssemblyResolveEventArgs args)
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.PlatformAssemblyResolver.AssemblyResolverEvent(Object sender, Object eventArgs)
   at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)

[rprouse]

If that's the case, then I think we'll need a very discoverable FAQ for that and an upvoted StackOverflow answer. I wouldn't want you to get flooded with issues 😉

[jnm2]

The legacy csproj format, using the package.config files and thus the old project system can not handle transitive dependencies. This is a blocker for changes we're doing in V4.

The legacy csproj format does not have to use the packages.config format. Legacy csproj has allowed the use of PackageReference (transitive dependencies) since around when PackageReference first appeared. If the problem is just with transitive dependencies, I think the adapter will be remaining compatible with legacy csproj, just not compatible with packages.config.

[ovebastiansen]

I don't see any problems moving forward in this direction. Like already said, there are some transient support in the old type, but also right in respect updating projects, if somebody is maintain some code on old types, they should update if possible.

Are you also doing anything related to what .net frameworks you will support? Might be time to drop some of the full framework versions