Error message "File type is not supported" when uses .nunit configuration file

[CharliePoole]

@NikolayPianikov commented on Mon Aug 15 2016

Version dev-03141
714679585.zip
NUnit.Extension.NUnitProjectLoader.3.5.0-dev-03141 exists in the "packages" directory.

[NikolayPianikov]

@CharliePoole I can't reproduce it on the last master branch, could we publish new packages to myget?

[CharliePoole]

Every time we build master branch in AppVeyor it is published to MyGet.

[NikolayPianikov]

So it looks very strange. It works only when I replace nunit\NUnit.ConsoleRunner.3.5.0-dev-03141\tools\nunit.engine.dll by my nunit.engine.dll compiled from a master branch.

[NikolayPianikov]

I found a problem. The package NUnit.ConsoleRunner.3.5.0-dev-03141 has nunit.engine.dll This assembly contains class NUnit.Engine.Runners.MasterTestRunner. Reflected code of this class is not a last version from the master branch and it contains bugs.
Reflected.zip

[NikolayPianikov]

Also I found a strange code in the class NUnit.Engine.Runners.DirectTestRunner, method LoadPackage()
// DirectRunner may be called with a single-assembly package // or a set of assemblies as subpackages. var packages = TestPackage.SubPackages; if (packages.Count == 0) packages.Add(TestPackage);
This code makes a cyclic tree of packages when the SubPackages collection is empty

[CharliePoole]

@NikolayPianikov Well, the package NUnit.ConsoleRunner.3.5.0-dev-03141
contains the output of Appveyor job 3141, which was run three days ago. It
was the last build of the nunit repository to contain engine and console
components. The next build, 3144, contains only framework components.

Unfortunately, now that console and engine runner are in a different
repository, AppVeyor started it's build numbers again. In addition, it
seems that the naming convention has reverted to an older pattern. You
should look at 3.5.0-CI-8-master. I'll see about fixing this so that the
pattern is correct and the numbers are higher than 3141.

The code you found is handling the case of a single assembly on the
command-line, which is a package with no subpackages. I did this to avoid a
lot of tests in the code that follows. However, it's probably a bug waiting
to happen and should be changed. It's not currently causing a bug because
we don't examine the graph any deeper after the point this code is used.

On Thu, Aug 18, 2016 at 5:47 AM, Nikolay Pianikov notifications@github.com
wrote:

Also I found a strange code in the class NUnit.Engine.Runners.DirectTestRunner,
method LoadPackage()

// DirectRunner may be called with a single-assembly package
// or a set of assemblies as subpackages.
var packages = TestPackage.SubPackages;
if (packages.Count == 0)
packages.Add(TestPackage);

This code makes a cyclic tree of packages when the SubPackages collection
is empty

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACjfhRKCexy4Nwets1Kg3rvQf10aWeEgks5qhFRxgaJpZM4Jk2qC
.

[rprouse]

@CharliePoole we can bump AppVeyor up to a build number that is higher than we were previously using in the settings. Shall I do this? Any reason not to?

[CharliePoole]

@rprouse Exactly! But look at build.cake as well. The code that formats the
pre-release suffix should match that in nunit. I don't know why it doesn't.

On Aug 18, 2016 8:23 AM, "Rob Prouse" notifications@github.com wrote:

@CharliePoole https://github.com/CharliePoole we can bump AppVeyor up
to a build number that is higher than we were previously using in the
settings. Shall I do this? Any reason not to?

[image: image]
https://cloud.githubusercontent.com/assets/493828/17779581/25fa98fa-6536-11e6-8104-2fc0bbb56ded.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACjfhc32kmPNwkuSwsvWYrkMBQHKjVadks5qhHjpgaJpZM4Jk2qC
.

[NikolayPianikov]

Now it is working
Thank you

[CharliePoole]

In some mysterious way, the naming of releases under NUnitConsole repo changed back to an older name pattern using -CI- rather than -dev-. I changed it (again) to match nunit's naming.

All the nunit-related builds should use the same naming but we can only implement that right now by copying the scripts from one repo to another. I wonder if there is some way we could put our tools in a common repo and pull them into our builds dynamically. Is this a use for subtrees?

[NikolayPianikov]

@CharliePoole @rprouse unfortunately this issue (File type is not supported) has appeared again

[CharliePoole]

As far as I can see, this is a New Issue that has never been fixed - or even worked on by anyone. So it's not surprising if it still exists. :-)

[NikolayPianikov]

Are there any rules which NuGet packages I should install to run integration tests on the last the consistent set of assemblies in the CI?

[NikolayPianikov]

Is it possible to use strict rules for dependency versions? For example for dev packages we could specify strict versions as [3.5.0-dev-03170] for all dependencies like for the target package. Or we could use not so strict rules, for example [3.5.0, 3.5.1) to have hot fixes but we should have a set of integration tests for all variants in the range [3.5.0, 3.5.1), otherwise if some package is not compatible it should receive next minor (or sometimes major) version - in this case 3.6.0 Moreover we should have branches for each major.minor versions and master branch to allow hot fixes and current development for each repo.

From my point of view it looks quite complex to have many plugins, several repos, several CIs, several compatible versions and to have well integrated tool without any checks of integration. And it brings stability risks. May be we should create another one CI to check an integration and use it as source of all nuget packages before their publication?

[CharliePoole]

I don't understand the problem you are seeing. The issue says that .nunit files are not supported. It's not fixed only because nobody has done any work on it, as far as I can see. I realize this is frustrating, but there are other priorities and the problem is not well-defined.

Are you saying that the problem relates to what versions you use together? If that's so, you should tell us what versions are involved.

My feeling is that you should normally be testing the extension against the latest release of the engine. However, since the very fact of separation is a new feature we are not currently in a normal situation and you may have to pick a stable dev version and test against that. I don't think you should be trying to test against every dev version because they are by nature transitory.

I agree that we need an integration test for any release candidate we produce. We are not doing continuous deployment however, so we have a little time to set it up.

Please excuse me though if I haven't understood the problem.

[CharliePoole]

An addition... this is more confusing to me now that I think more about it. The nunit-project-loader extension is not yet split from the engine. The two are released together. So you should always have a compatible version of those two. The only variable is the version of the teamcity extension that you are creating.

A question then: are you changing the base version of the console runner that you use with each run?

[NikolayPianikov]

I did not do any changes at all. But TC tracks MyGet feed and runs tests for the latest NuGet packages. I've already described the issue in my previous message: "I found a problem. The package NUnit.ConsoleRunner.3.5.0-dev-03141 has nunit.engine.dll This assembly contains class NUnit.Engine.Runners.MasterTestRunner. Reflected code of this class is not a last version from the master branch and it contains bugs. ... Example was attached"

[CharliePoole]

Right... the original problem was due to a naming error in our MyGet feed. That was fixed without actually working the problem. We would have closed the issue, but then you indicated it was still a problem so I left it as still a "new issue". But the specific problem you cited should be gone.

That's good, but also bad. The bad part is that we now have no idea what is causing the problem for you. :-(

If you are running integration tests with every new dev build, are you ensuring that the version of ConsoleRunner you get matches the version of the NUnit project loader? Are you using a stable version of your own extension or are you building the latest code?

My assumption was that every extension developer would test against the last release version as their primary integration. I think that the dev releases are important, but the release versions are more so.

Since this issue has changed definition during it's short life, it might help if you could summarize what the current problem is. Beyond that, we are of course waiting for somebody to self-assign the issue, but it may help motivate one of the committers if you can clarify what exactly needs to be fixed.

For the moment, I'm triaging this as a bug but needing confirmation to be sure it's not just an error in configuration.

[ngbrown]

I've used only the release zips available on the website and found that 3.0.1 gives an error "Format of the executable (.exe) or library (.dll) is invalid." when passed an .nunit file.

Version 3.2.1 Accepts .nunit files and appears to work fine.

Version 3.4.1 gives the error "File type is not supported" when passed a .nunit file. I was not using any addins.

[CharliePoole]

@ngbrown Thanks for the info.

Every version of NUnit should give an error if you try to use a .nunit file without having installed the nunit project loader extension. Earlier versions give the funny error you saw with 3.0.1 rather than the cleaner "File type is not supported" error.

In the case of 3.2.1, you must have installed the extension, either directly or as a dependency of something else you installed. For example the NUnit.Console nuget package includes the extension.

I'm pretty sure that 3.4.1 will load a .nunit file if you install the extension.

[ngbrown]

@CharliePoole my mistake. For some reason I thought that I didn't need the addins directory and so was leaving it out. I must have accidentally left it in when testing 3.2.1. Sorry for bothering you with this.

[CharliePoole]

No problem. It's really a bit obscure and we have to do a better job of explaining it.

[rprouse]

Fixed by PR #52. Entering new issue for remaining work.

[gottscj]

just used a half day trying to get the console runner to accept the .nunit project file.
It would be nice if:

1. the output was more descriptive than "File type not supported", maybe add "Did you install the 'NUnit.Extension.NUnitProjectLoader' nuget?"
2. You guys added this information to the documentation page on github.

Thanks. :)

(edit: grammar)

[mikkelbu]

Hi @gottscj
Regarding 1.
I don't think that the console has any notion of "special" extensions. NUnitProjectLoader is an extension like all the other project loader extensions, but perhaps we can make a generic statement like "Perhaps you need to install an extension to load file XYZ"

Regarding 2.
You are right that we should add a FAQ or similar that contains something about this. Currently, there are a little about the project loaders on the wiki, see Project-Loaders and Packaging-Extensions, but it does not state what the project loaders are for.