Can't get the Reqnroll solution to compile properly

[mbhoek]

Clean checkout, clean build (i.e. "Build/Rebuild Solution"). I get error messages like The "GenerateFeatureFileCodeBehindTask" task failed unexpectedly. And a lot of warning MSB3026: Could not copy "C:\[..]\Reqnroll\Reqnroll\bin\Debug\net462\Reqnroll.dll" to "bin\Debug\net462\Reqnroll.dll". Beginning retry 6 in 1000ms. The process cannot access the file 'bin\Debug\net462\Reqnroll.dll' because it is being used by another process. The file is locked by: "MSBuild.exe (16820)".

• Visual Studio 17.9.0 and Reqnroll 1.0.1
• have uninstalled all SpecFlow/Reqnroll extensions
• .\build.ps1 works as intended, no errors
• .\runtests.ps1 appears to do nothing

Was a about to raise a "Bug Report" but that template doesn't accommodate for plugin developers. Please let me know if this is not the proper way to report, but I'm stuck here.

What am I doing wrong?

[ajeckmans]

This is actually what I experienced on my laptop as well. The solution builds on my work laptop which also has older .net framework tooling installed, which my own laptop does not.

[Tiberriver256]

I was having that problem intermittently as well. Deleted all bin and obj folders and then re-ran build.ps1 and it would occasionally work.

[clrudolphi]

I haven't attempted to recreate this yet, but it sounds like the known issue with Visual Studio locking files during builds.
The work-around is documented in the Contributing.md file as:
Set the MSBUILDDISABLENODEREUSE environment variable to 1

This is automatic in the build.ps1 as it provides that value as a command line parameter to msbuild. That explains why the build works from the command line but not within VS.

HTH

[ajeckmans]

Yes but that is where the project configuration comes in right?

[gasparnagy]

Unfortunately not. The problem comes during build time.

[ajeckmans]

Well then we also have the Directory.Build.rsp file. Although I'm not sure if visual studio honours it. I know we have one set on our self-hosted azure build agents to mimic the ones from Microsoft and any invocation of msbuild (directly or through dotnet) gets the -nodeReuse:false added.

[gasparnagy]

@ajeckmans Yeah, it worth trying it out, but please don't get too excited! I have this env variable set for ages and I still keep having the locking problem ☹️ (see my workarounds below)...

[ajeckmans]

Apparently this is already done :)

[gasparnagy]

This is unfortunately a known problem that we inherited from SF, that we need to address ASAP.

The problem is that the MsBuild task of Reqnroll is used by the "Specs" tests and VS locks the result in various ways.

My (not always working) workaround is:

• before opening VS, do a dotnet build from a console.
• open vs, and unload the project "Reqnroll.Tools.MsBuild.Generation" and the related integration test (VS will remember this)
• the lock will happen less frequently, but if it happens, you need to restart VS
• having the "test explorer" window closed or hidden also reduces the chance of locking (if you can run the tests with ReShaper)

[Tiberriver256]

Got what seems to be a reliable fix set up in this PR:
#64

Trick was to set the TaskFactory="TaskHostFactory" attribute on the tasks to make sure msbuild was killed immediately after the tasks run.

[Tiberriver256]

@mbhoek - This just merged if you want to give it another go when you can.