Nant build issue: Failed to initialize the Microsoft .NET compact framework - build

i have some problems regarding building .NET solution for handheld device using NAnt 0.92. The solution consists of typical csproj and CAB installer (vddproj). The target platform is .NET CF 3.5.
However, if i set the target platform in the script as:
< property name="nant.settings.currentframework" value="netcf-3.5" />
when i execute then i receive an error:
Target framework could not be changed. "netcf-3.5" is not a valid framework identifier.
This means that i cannot build solutions for target platform 3.5. Logically, i have tried with CF 2.0 afterwards:
< property name="nant.settings.currentframework" value="netcf-2.0" />
and then i receive an error
Failed to initialize the 'Microsoft .NET Compact Framework 2.0' (netcf-2.0) target framework. Registry path not found! - key = 'SOFTWARE\MICROSOFT......'
I have the proper SDK installed as some other posts suggested. Also, tried to disable the antivirus, as also suggested in similar posts, but couldn't find any solution.
Can you give any advice, please?
Thank you in advance. Daniel

I know it's a bit late but I would suggest that you're using NAnt only to trigger MSBuild.exe. Thats what we're doing in our CI environment and it works perfectly. Also make sure that your project is a smart device project or else it won't build correctly. I'm not even sure if NAnt supports the CF 3.5 (anymore).

Related

SpecFlow/MSBuild Codebehind Gen - Generate All task

On a project I am working on, I am maintaining some Feature Tests written in SpecFlow. Our team started using Visual Studio 2017 about a year ago, and we finally got around to doing some upkeep on our tests!
Our tests for the project I'm working on were originally written in SpecFlow 2.3.2, and were last updated in Visual Studio 2015.
The SpecFlowSingleFileGenerator is known to not work on VS 2017, so I spent the better part of yesterday changing our suite to use the MSBuildSingleFileGenerator instead as detailed in this article in SpecFlow's official documentation
Problem:
Locally, I can build my solution, including the Feature Test project just fine.
However, I keep getting the following error when I try to build the project on our build server:
[exec] C:\CheckoutDirectory\My Awesome Project\packages\SpecFlow.Tools.MsBuild.Generation.2.3.2\build\SpecFlow.Tools.MsBuild.Generation.targets(45,5):
error MSB4036: The "GenerateAll" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin" directory. [C:\CheckoutDirectory\My Awesome Project\AwesomeProject.FeatureTest\AwesomeProject.FeatureTest.csproj]
I should point out that our team has no experience with writing MS Build tasks, as hitherto we haven't needed to; we use NAnt build scripts on TeamCity to manage our build work. It's clear that error message would be helpful...if we knew literally anything about it.
Now, normally the correct answer would be: Google it. I did that, and this specific error has no pertinent results.
Additionally, this is blocking my team, since we need our build to work. I don't have the time to do the research and education necessary to properly understand how MS Build technology works. That wil have to come later.
Question:
Bearing in mind that SpecFlow has broken our process, and our team's lack of knowledge about the MS Build system: I need to know how to get around the "GenerateAll" task was not found error. What do I do to get around it?
Secondary Question:
I'm also open to lateral thinking. Is there some way to hack either VS 2017 or SpecFlow to make the SpecFlowSingleFileGenerator "compatible" with each other? The objective here is NOT to avoid making changes, but to control the changes. I need a path towards transitioning from the old file generator to the MS build generation system.
Additional Information:
So, I did some digging, and I found a place where "GenerateAll" is being called in the SpecFlow.Tools.MsBuild.Generation.targets file:
<Target Name="UpdateFeatureFilesInProject"
DependsOnTargets="BeforeUpdateFeatureFilesInProject"
Inputs="#(SpecFlowFeatureFiles)" Outputs="#(SpecFlowFeatureFiles->'%(RelativeDir)\%(Filename).feature.cs')">
<GenerateAll
ShowTrace="$(ShowTrace)"
BuildServerMode="$(BuildServerMode)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
ProjectPath="$(MSBuildProjectFullPath)"
ForceGeneration="$(ForceGeneration)"
VerboseOutput="$(VerboseOutput)"
DebugTask="$(SpecFlow_DebugMSBuildTask)"
>
<Output TaskParameter="GeneratedFiles" ItemName="SpecFlowGeneratedFiles" />
</GenerateAll>
</Target>
Because I've confirmed that this is being copied out to the build server, the situation is yet more mysterious. It appears that the NuGet package is being pulled down faithfully. Therefore, I can't figure out why my local copy is behaving differently than the copy on the build server.
I am not sure where you found this statement:
The SpecFlowSingleFileGenerator is known to not work on VS 2017
The SpecFlowSingleFileGenerator is working in VS2015, VS2017 and VS2019. We see it as a legacy feature, but it's still there. Since some weeks it is disabled by default, but you can enable it in the options.
It works for SpecFlow >= 2.3.2 and 2.4. For SpecFlow 3 you have to use the MSBuild integration. There are some problems with older versions of SpecFlow, but with them it can also work. It depends on your setup.
About your MSBuild error:
The MSBuild Task for SpecFlow < 3.0 is in the specflow.exe. Is it on your build server?
It is part of the SpecFlow NuGet packages. Normally you get this kind of error if MSBuild can't find the assembly where the task is.
For "debugging" problems with MSBuild, I can highly recommend to use the MSBuild Structured Log Viewer (http://msbuildlog.com/). With it, it makes it easy so see what is happening in your build.
We have an example for MSBuild Code- Behind- Generation with SpecFlow 2.3.2 here: https://github.com/techtalk/SpecFlow-Examples/tree/master/MSBuild/OldCSProj_SpecFlow232
You could compare your project with this example.
Full disclosure: I am one of the maintainers of SpecFlow.

The specified Microsoft.NETCore.App', version '2.0.7' was not found

cannot start .NET Core app because of this error:
"It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.0.7' was not found.
- Check application dependencies and target a framework version installed at:
\
- Alternatively, install the framework version '2.0.7'.
The program '[1560] dotnet.exe' has exited with code -2147450749 (0x80008083)."
Editing .csproj didn't help. It looks like this:
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeFrameworkVersion>2.0.7</RuntimeFrameworkVersion>
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
You don't have the right .NET Core runtime installed. It's not good enough that's a .NET Core 2 runtime; it needs to be a minor version that is equal to or encompasses the version you're trying to target. You can see all the available runtimes here: https://www.microsoft.com/net/download/all. Specifically, you need 2.0 Runtime (v2.0.7) or higher. You can just choose 2.1, though. 2.0.7 will be rolled in and then, if you do end up upgrading your project later, you won't run into this issue again.
After playing around for a (longer) while, eventually it turned out that the solution is to comment out RuntimeFrameworkVersion in .csproj:
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<!--<RuntimeFrameworkVersion>2.0.7</RuntimeFrameworkVersion>-->
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
It is worth mentioning that the problem occured after my collegues upgraded a .NET Core to higher version and I did 'Get latest version'.

Running SpecFlow Report - ERROR - The attribute "Label" in element <Target> is unrecognized

I have been following the tutorial found here for a SpecFlow test report generator.
My issue is, when I run the tool, I receive the following message:
The attribute "Label" in element Target is unrecognized
I've found a few possible solutions, none of which have worked e.g. here
I am able to show that I am running version 4.x as when I run MSBuild using the Visual Studio 2012, command prompt I can see the following:
Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET
Framework, version 4.0.30319.18052]
I have created a config file as suggested here
but unfortunately I am still getting the error. The project is running locally off git and this issue has been fixed in the past by using the config file, however since swapping to a VMware Virtual machine, it is now occurring again.
I have also right clicked > Properties which states that the file is using .NET 4.0, in addition created a Environment Variable linking directly to the MSBuild directory. I've spent a good while browsing the internet and cannot get this working. Please help!
Many thanks for any help you can provide,
Cheers!
Solved this with the internal devs. There was some problem with the Chromedriver update script which had been added by (I'm assuming NuGet)
Starting
<PropertyGroup Label="DownloadChromeDriverBuildTask">
and also:
<Target Name="DownloadChromeDriver" Label="DownloadChromeDriverBuildTask">
It was a small script that was installing ChromeDriver if it was not already available. Removing this seems to have resolved it. Hope this provides help to anyone with a similar issue.

How to force NAnt to use gmcs while csc.exe is available on Windows

I am setting up a new project to play around with the CLR and mono versus .NET. As a build environment/tool I chose NAnt, because I am familiar with Ant and it seemed best suiting.
While this is working very nice on different machines with different OSs, I am worried that some day, while I develop on a Windows machine, gmcs may not be able to build my sources, making them unavailable to other platforms using mono. So my idea to get around this is telling NAnt to always use gmcs inside the <csc> task. Is there a way to set the build script up that way? Or another workaround for my problem?
You can select the desired compiler using the default attribute of the plateform element in the configuration file Nant.exe.config.
You can also choose at runtime by using the -t switch. In example :
nant -t:net-4.0 will use csc and will target the .NET framework 4.0
nant -t:mono-2.0 will use mcs and will target the .NET framework
2.0

Way to debug mixed JNI code?

I've been looking around to find an easy way to debug my JNI code, you know, to be able to freely jump into native code and back into java code.
The solutions which I found were sort of out of date or got some restrictions. Some required specific ndk version, some required specific Eclipse version. Here my target is Android 1.6 & 2.2, I'm using Eclipse 3.6 Helios, and NDK r5b. Is there a general solution for this mixed debugging? Thx.
Citate from $NDK/docs/NDK-GDB.html:
IMPORTANT: Native debugging can only work if all these conditions are met:
1. Your application is built with the 'ndk-build' script:
Building with the legacy "make APP=<name>" method is not
supported by ndk-gdb.
2. Your application is debuggable:
In other words, your AndroidManifest.xml has an <application>
element that sets the android:debuggable attribute to "true"
3. You are running your application on Android 2.2 (or higher):
ndk-gdb will not work if you try to run your application on
previous versions of the system. That does not mean that your
application should target the Android 2.2. API level, just
that the debugging session should happen on a 2.2+ device or
emulator system image.
so, you can't use device with 1.6.
How to setup environment to debug jni code: i used this recipe, it works for me.