Parse csproj file using cake's ParseProject - cakebuild

Create minimal repro project:
dotnet new classlib --no-restore --output /tmp/Foo
cd /tmp/Foo
dotnet new tool-manifest
dotnet tool install cake.tool
touch build.cake
Put this minimal script in build.cake:
Task("Default").Does(() => {
var file = "./Foo.csproj";
Information(FileExists(file).ToString());
var props = ParseProject(file);
});
RunTarget("Default");
Run it:
dotnet cake
Result:
========================================
Default
========================================
True
An error occurred when executing task 'Default'.
Error: Failed to parse project properties
Surely this minimal script should succeed - have I made a mistake, or is this a bug?
My environment: linux, dotnet 6.0.302.

Out of box, the ParseProject alias within Cake (version 2.2.0), only knows how to parse Visual Studio Project files that are using the "old" format.
Since the Visual Studio Project file that you are creating is using the "new" format (i.e. it was generated using the dotnet CLI, and is targetting .NET Core), the ParseProject in Cake will not be able to recognise it.
There is however an alternative ParseProject alias in the Cake.Incubator addin that can do what you want. You can make use of this by doing:
#addin nuget:?package=Cake.Incubator&version=7.0.0
Task("Default").Does(() => {
var file = "./cake-test.csproj";
Information(FileExists(file).ToString());
var props = ParseProject(file, "Release");
});
RunTarget("Default");
Result:
========================================
Default
========================================
True
Task Duration
--------------------------------------------------
Default 00:00:00.0496415
--------------------------------------------------
Total: 00:00:00.0496415
At some point, the work in the Cake.Incubator addin will likely be merged into Cake, and will ship as a new version, however, for now, you will need to bring in the addin directly.

Related

Run script and add files to Swift Package via BuildToolPlugin

Context
I recently took over a Swift project which relies on git submodules. One of my first task was to clean up the project, which means removing submodules, using Swift Packages.
On my way doing this i encounter a tricky submodule. It contains swift files and a WebPack project that's loaded in a WebView. Currently the project that imports this submodule has a custom build phase that runs npm ci + npm build to build the WebPack and copy the files into the app.
Question:
When i switch to using a Swift Package it should manage this custom build phase on its own. Is it possible to run npm ci + npm build in a BuildToolPlugin?
My current state is trying to run a shell script which simply creates a file:
#main
struct TSPlugin: BuildToolPlugin {
func createBuildCommands(context: PackagePlugin.PluginContext, target: PackagePlugin.Target) async throws -> [PackagePlugin.Command] {
let tsPath = context.pluginWorkDirectory
.appending (subpath: target.name)
.appending (subpath: "Seatmap")
print(tsPath)
print("here1")
let scriptPath = context.package.directory.appending(["..", "TSPlugin", "TEst.sh"])
print("here2")
return [
.prebuildCommand(
displayName: "Generating localized strings from source files",
executable: scriptPath,
arguments: [],
outputFilesDirectory: tsPath
)
]
}
}
#!/bin/bash
echo "come on"
touch easypeasy.txt
I rebuilt this in a demo project: https://github.com/Deitsch/SwiftPluginDemo

Unable to run/debug robot tests in vscode - robocorp extensions installed

I have installed Robocorp Code as well as Robot Framework Language Server and have configured them. However, I am still having errors when trying to run the tests via the code lens options.
Repo - A webapi repo with a specific folder containing all tests. Lets call it regression.
RF - 4.1.3
Python - 3.8
This is what happens when I click on Run on the code lens for any of the tests -
`PS C:\git\xxxx\regression> C:; cd 'C:\git\xxxx\regression'; &
'C:\Users\xxxx\AppData\Local\Temp\rf-ls-run\run_env_00_smh5defr.bat'
'-u'
'c:\Users\xxxx.vscode\extensions\robocorp.robotframework-lsp-0.47.2\src\robotframework_debug_adapter\run_robot__main__.py'
'--port' '54331' '--no-debug' '--argumentfile'
'C:\git\xxxx\regression\args-local.txt' '--pythonpath'
'c:\git\xxxx\regression\common\lib' '--variable'
'EXECDIR:C:/git/xxxx/regression'
'--prerunmodifier=robotframework_debug_adapter.prerun_modifiers.FilteringTestsSuiteVisitor'
'c:\git\xxxx\regression\api\api_Test.robot'
[ ERROR ] Parsing'--pythonpath' failed: File or directory to execute does not exist.
However, the test starts if I remove the argumentfile parameter but it, of course, fails because its missing arguments from the file.
Do note that the folder specified in pythopath exists and has some python libraries needed for the tests.

How to run an EXE file compiled from a F# source on the Mac Terminal?

I have a hello world program in F#.
open System
[<EntryPoint>]
let main argv =
printfn "Hello World from F#!"
0 // return an integer exit code%
On an Mac OS, I can compile it with "fsharpc", which generates two files
FSharp.Core.dll hello.exe
The EXE file certainly looks strange on a Mac. But how can I execute it from the command line, without using a project structure (because it seems an overkill) like what is explained here: https://dotnet.microsoft.com/learn/languages/fsharp-hello-world-tutorial/create
Actually if I run "dotnet hello.exe", I get this error:
A fatal error was encountered. The library 'libhostpolicy.dylib'
required to execute the application was not found in
'/Users/zell/hello/'. Failed to run as a self-contained app. If this
should be a framework-dependent app, add the
/Users/zell/hello/hello.runtimeconfig.json file specifying the
appropriate framework.
You can create and build/run F# apps like so:
dotnet new console -lang F# -o SomeDirectory && cd SomeDirectory
dotnet run
Building it without running is:
dotnet build
You can see a reference for all commands here: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet
You appear to have Mono installed, which is where fsharpc comes from. I wouldn't recommend using that unless you are doing mobile development with Xamarin, which currently requires Mono.
By trial and error, I found to run my new .exe file, I needed a .runtimeconfig.json file in the same folder with same without-the-extension-name, i.e. hello.runtimeconfig.json:
{
"runtimeOptions": {
"tfm": "net5.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "5.0.0"
}
}
}
Then dotnet hello.exe will work.

Deploying .NET Core Application with Windows Compatibility Pack

I'm busy deploying a .NET Core 2.1 application into our testing environment, but I'm getting the following error.
Error:
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'System.Diagnostics.EventLog', version: '4.5.0'
path: 'runtimes/win/lib/netcoreapp2.1/System.Diagnostics.EventLog.dll'
We are using the Windows Compatibility Pack to access the Event Log.
I have the following item in the dependency Json file:
"System.Diagnostics.EventLog/4.5.0": {
"dependencies": {
"Microsoft.Win32.Registry": "4.5.0",
"System.Security.Permissions": "4.5.0",
"System.Security.Principal.Windows": "4.5.0",
"System.Threading.AccessControl": "4.5.0"
},
"runtime": {
"lib/netstandard2.0/System.Diagnostics.EventLog.dll": {
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
},
"runtimeTargets": {
"runtimes/win/lib/netcoreapp2.0/System.Diagnostics.EventLog.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
}
}
Please advise how one should deploy these dependencies. Also, what is the root folder to this relative path runtimes/win/lib/netcoreapp2.0?
We actually found a solution for our scenario:
- Our situation was that we tried to run a netcoreapp based test project on our test agent
- dotnet test on the project file worked
- dotnet vstest sometimes worked on the project output directory (we are not sure why and on which setup)
- dotnet vstest did run into the above error when run into an other directory & downloaded from CI
- dotnet vstest did run into an AssemblyNotFoundException on the test agent (which didn't make any sense for us)
The solution was to use dotnet publish for our test project and use the "self-contained" output to run on the test agent. dotnet publish copied the required runtimes/win/lib/netcoreappX.X/*.dll files into the publish output directory.
After a lot of testing, the key issue seems to be the "RuntimeIdentifiers". There is a visible option for this when you publish, but in order to use it when just building you need to add a couple of tags to your .csproj file.
The first is:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
This will cause NuGet to retrieve the correct dlls (change the value depending on your needs). For me I was compiling to platform x86. I don't know what NuGet was getting by default, but whatever it was had different file sizes for the same files.
You also should then add this tag:
<SelfContained>false</SelfContained>
or else your build will default to copying the entire framework.
Also note that using the RuntimeIdentifier tag will cause your default output folder to include the value you specified. For example my subfolder became:
Project\bin\x86\Debug\netcoreapp3.1\win-86\
For publishing you should be able to do something similar; the problem will be to match your RuntimeIdentifier to your platform. You shouldn't need to specify SelfContained unless you specifically need to.

Building/Running/Tasks multiple dotnet project in Visual Studio code?

I have a project structure like the following and I would like to be able to run tasks on all projects at once so that i maybe able to build and run as well as run tests on all projects in one command using Visual Studio code? is this possible?
-global.json
-src
-Web
-project.json
-program.cs
-Web2
-project.json
-program.cs
-test
-Web.Test
-project.json
-program.cs
-Web2.Test
-project.json
-program.cs
You can add a solution file to your root folder with dotnet new sln. You can then add project references with dotnet sln add : https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-sln
dotnet build will then build all referenced projects, and dotnet test will run all unit tests found.