We Keep Coding

Attempting to figure out the EntityFramework metadata for the model and DbContext: 'Employee'

I am trying to generate drivers from the command ..
dotnet aspnet-codegenerator controller -name EmployeeController -m Employee -dc EmsContext --relativeFolderPath Controllers --useDefaultLayout --referenceScriptLibraries
Attempting to figure out the EntityFramework metadata for the model and DbContext: 'Employee'
A file matching the name MvcControllerWithContext.cshtml was not found within any of the folders:
at Microsoft.VisualStudio.Web.CodeGeneration.ActionInvoker.<BuildCommandLine>b__6_0()
at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
at Microsoft.VisualStudio.Web.CodeGeneration.ActionInvoker.Execute(String[] args)
at Microsoft.VisualStudio.Web.CodeGeneration.CodeGenCommand.Execute(String[] args)
It is the last step according to a documentation, I am starting with this Framework but I cannot get out of this status. I am using Ubuntu and all through the terminal. If someone can give me an indication of how to solve it, I would really appreciate it.

As #ericc-eacs Answer, you need to copy the template and in case you just following the getting started tutorial(.net core), make sure to remove the folder to the template of identity as when you build it will give some errors. You just need the templates to create the views and controllers.

What version of the dotnetcore SDK are you using?
dotnet --version
You may need to install a different version of the aspnet-codegenerator.
Some helpful commands:
dotnet tool uninstall --global dotnet-aspnet-codegenerator
dotnet tool install --global dotnet-aspnet-codegenerator --version 3.1.0
dotnet tool update -g dotnet-aspnet-codegenerator

I have the solution for UBUNTU valid for net core 3.0, 3.1, and 5.0.
27/NOVEMBER/2020
ControllerGenerator contains de file MvcControllerWithContext.cshtml
You just copy the Templates folders Template/ControllerGenerator and Template/ViewGenerator to own project.
Look the version in this example is 5.0.0enter image description here
This is the path of the missing files: /home/$USER/.nuget/packages/microsoft.visualstudio.web.codegenerators.mvc/5.0.0/Templates

I can confirm that this issue exists at least since november and have not found solution for it. Using Ubuntu 18.04.5 LTS, Rider EAP 2020.3. C# 9, dotnet-aspnet-codegenerator version '5.0.1', dotnet 5.0.102.
When running the utility to build crud pages for Razor Pages web app:
dotnet aspnet-codegenerator razorpage -m GpsSession -dc ApplicationDbContext -udl -outDir Pages/GpsSessions --referenceScriptLibraries
The following output is given:
Building project ...
Finding the generator 'razorpage'...
Running the generator 'razorpage'...
Attempting to figure out the EntityFramework metadata for the model and DbContext: 'GpsSession'
A file matching the name Create.cshtml was not found within any of the folders:
at Microsoft.VisualStudio.Web.CodeGeneration.ActionInvoker.<BuildCommandLine>b__6_0()
at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
at Microsoft.VisualStudio.Web.CodeGeneration.ActionInvoker.Execute(String[] args)
at Microsoft.VisualStudio.Web.CodeGeneration.CodeGenCommand.Execute(String[] args)
When I run the same command on same repository in Win10 then everything works perfectly, crud pages are generated without any errors.

Automatically signing ALL compiled output files

I have a .net-core 3.1 project (Microsoft.NET.Sdk.Web) in gitlab, and am setting up a CI/CD pipeline for it. As the final step, I want to have all the .dll and .exe output files signed by our key. I can do this by manually putting in some 'signtool' commands as a part of the gitlab-ci.yml file, however that requires going into each project and manually tweaking the file to reflect the specifics of that project.
On the other hand, I have been able to add a generic target in the .csproj file which calls signtool as an exec/command on $(TargetDir)$(TargetFileName). This works to a degree - but it doesn't sign everything. In this case, it signs (e.g.) cthulhu.dll, but not also cthulhu.Views.dll (both of which are shown in the CLI output of 'dotnet msbuild') and there's also a cthulhu.exe that is generated but is not shown in the msbuild output and also not signed.
The csproj file has this as the target (tried running both after rebuild and after publish):
<Target Name="SignAssembly" AfterTargets="Rebuild">
<Message Text="Signing assembly '$(TargetDir)$(TargetFileName)'" Importance="high" />
<Exec Command="signtool sign /f "mykey.pfx" /p "snip" /tr http://timestamp.digicert.com "$(TargetDir)$(TargetFileName)"" />
And the gitlab-ci.yml file looks like this (I'm aware that I'm using the sdk docker container, but it seems to let me support .net-core builds anyway, whereas there is a bug preventing the specific .net-core container from working):
image: mcr.microsoft.com/dotnet/framework/sdk:4.8
stages:
- build
- release
build:
stage: build
script:
- 'dotnet build -r win-x64'
release:
stage: release
script:
- 'dotnet add package signtool --version 10.0.17763.132'
- 'dotnet msbuild cthulhu.csproj /t:"Restore;Rebuild;SignAssembly;Publish" /p:SelfContained=True /p:PublishProtocol=FileSystem /p:Configuration=Release /p:Platform=x64 /p:TargetFrameworks=netcoreapp3.1 /p:PublishDir=bin\Release\netcoreapp3.1\publish\win-x64 /p:RuntimeIdentifier=win-x64 /p:PublishReadyToRun=False /p:PublishTrimmed=True'
artifacts:
name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
paths:
- '.\bin\Release\netcoreapp3.1\publish\win-x64'

Why not use standard tools - Directory.Build.props?
However, now you can add a new property to every project in one step
by defining it in a single file called Directory.Build.props in the
root folder that contains your source. When MSBuild runs,
Microsoft.Common.props searches your directory structure for the
Directory.Build.props file (and Microsoft.Common.targets looks for
Directory.Build.targets). If it finds one, it imports the property.
Directory.Build.props is a user-defined file that provides
customizations to projects under a directory
Indicates that the assembly should be signed:
<SignAssembly>true</SignAssembly>
The key is specified using the following property:
<AssemblyOriginatorKeyFile>key.pfx</AssemblyOriginatorKeyFile>
That is, as a result, these properties will be imported into the projects and you will achieve the desired result.

How do I auto-increment nuget package version using VSTS build process?

In this video from MSDN at the 3:34 second mark, the presenter shows how to append the Build ID to a nuget's version. In the MSBuild arguments, he specifies:
/t:pack /p:PackageVersion=1.0.$(Build.BuildId)
So, when the project is built by VSTS, the nuget assembly's revision number is using the build id.
I would like to do something similar. Instead of hard coding the 1.0 in the build definition, I'd like to retrieve that from .csproj file. I am using the new .csproj file which stores nuget information.
For example, I'd like to specify in the csproj:
<Version>0.0.1-beta</Version>
Then, VSTS would append the BuildID and generate the assembly version as 0.0.0.1-beta.49 (49 being the build id)

I ended up doing the opposite of what Shayki Abramczyk suggested.
I use a task called "Variables Task Pack". It can be found here (and is free at the time of this answer): https://marketplace.visualstudio.com/items?itemName=YodLabs.VariableTasks#qna
Using this task, I set two variable: $(BuildId) and $(ReleaseType). See the settings snapshots at the end of the answer.
Then, in my CSPROJ project file, I modified the nuget version to use the two environment variables. Here's a clip of the project file:
<PropertyGroup>
<Version>0.0.0.0$(BuildId)$(ReleaseType)</Version>
<FileVersion>0.0.0.0$(BuildId)$(ReleaseType)</FileVersion>
...
</PropertyGroup>
IMPORTANT: Notice the extra 0 in front of $(BuildId). I had to add that in order to build locally. Without it, the build failed with an incorrect version format error.
Now, after building, I get the buildid as my revision number and release type appended.
Here are the screen shots showing configuration of both variables.

You can create a Power Shell script that retrieves the version from csproj file, then add the version to a new environment variable with this command: Set-VstsTaskVariable
For Example:
$csprojId = $retrivedIdfromTheFile
Set-VstsTaskVariable -Name "CSPROJ_ID" -Value $csprojId
Now you can use the CSPROJ_ID variable on the MSBuild arguments:
/p:PackageVersion=$(CSPROJ_ID).$(Build.BuildId)

SonarQube unrecognized command line argument c#

I'm having trouble running a scann for my c# app, I'm trying to scan a simple console application. but everytime I run my analysis I get this:
16:00:04.919 16:00:04.919 Unrecognized command line argument: /t:Rebuild
So here's the complete command since the beginning:
PS C:\Users\danie\documents\Visual Studio 2015\Projects\ConsoleApplication1> C:\SonarQube-Scanner-for-MSBuild\SonarQube.Scanner.MSBuild.exe begin /k:"ConsoleApplication1" /n:"ConsoleApplication1"/v:"1.0"
SonarQube Scanner for MSBuild 4.0.2
Default properties file was found at C:\SonarQube-Scanner-for-
MSBuild\SonarQube.Analysis.xml
Loading analysis properties from C:\SonarQube-Scanner-for-
MSBuild\SonarQube.Analysis.xml
Pre-processing started.
Preparing working directories...
16:13:12.659 Updating build integration targets...
16:13:12.674 Fetching analysis configuration settings...
16:13:13.051 Provisioning analyzer assemblies for cs...
16:13:13.052 Installing required Roslyn analyzers...
16:13:13.152 Pre-processing succeeded.
PS C:\Users\danie\documents\Visual Studio 2015\Projects\ConsoleApplication1>
C:\SonarQube-Scanner-for-MSBuild\SonarQube.Scanner.MSBuild.exe /t:Rebuild
SonarQube Scanner for MSBuild 4.0.2
Default properties file was found at C:\SonarQube-Scanner-for-
MSBuild\SonarQube.Analysis.xml
Loading analysis properties from C:\SonarQube-Scanner-for-
MSBuild\SonarQube.Analysis.xml
WARNING: Please specify the command 'begin' or 'end' to indicate whether
pre- or post-processing is required. These parameters will become mandatory
in a later release.
Pre-processing started.
Preparing working directories...
16:13:17.069 16:13:17.053 Unrecognized command line argument: /t:Rebuild
16:13:17.069 16:13:17.053 A required argument is missing: /key:[SonarQube
project key]
16:13:17.069 Expecting at least the following command line argument:
- SonarQube project key
When connecting to a SonarQube server earlier than version 6.1, the following command line arguments are also required:
- SonarQube project name
- SonarQube project version
The full path to a settings file can also be supplied. If it is not supplied, the exe will attempt to locate a default settings file in the same directory as the SonarQube Scanner for MSBuild.
Use '/?' or '/h' to see the help message.
16:13:17.084 Pre-processing failed. Exit code: 1
Any help fixing this will be appreciatted!
Thanks.
PD: I'm running sonarqube version 6.7.1 and MSBuild

The second command you execute should be just msbuild.exe, not SonarQube.Scanner.MSBuild.exe.
Edit:
The problem, is indeed that I have to execute MSBuild.exe instead of the other one but if you can't execute that, it may be because you don't haven't configured your environment varables, and path. If you can't execute it simply look for your MSBuild folder in Program Files (x86), in the end you should execute this:
'C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe' /t:Rebuild
so this should be it.

Run Microsoft Visual Studio C# project in Linux

I downloaded a c# .net project from git onto ubuntu and installed .net libraries from http://www.mono-project.com/download/#download-lin and also donet core from https://www.microsoft.com/net/core#linuxubuntu.
when I run donet restore, I am getting the following error
/home/ubuntu/DotNetWallet/src/DotNetWallet/DotNetWallet.xproj(8,3): error MSB4019: The imported project "/usr/share/dotnet/sdk/1.0.3/Microsoft/VisualStudio/v14.0/DotNet/Microsoft.DotNet.Props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I guess the problem is with the DotNetWallet.xproj which generally is compatible with visual studio but how can I run it on ubuntu?
So, I
used 'dotnet migrate' ,and then used 'donet restore', it now works fine, but when I run 'donet build', I am getting the following error
FakeData.cs(1,20): error CS0234: The type or namespace name 'KeyManagement' does not exist in the namespace 'DotNetWallet' (are you missing an assembly reference?) [/home/ubuntu/DotNetWallet/src/DotNetWallet/DotNetWallet.csproj]
And, here is the git repo link https://github.com/nopara73/DotNetWallet

Many step are required in order to run this project.
First delete global.json file and then run dotnet migrate and remove the backup directory.
(Optional) In some case you will need to clean the solution. If DotNetWallet.xproj and project.json are still there, remove it and run the twxo following command.
dotnet sln remove src/DotNetWallet/DotNetWallet.xsproj
dotnet sln add src/DotNetWallet/DotNetWallet.csproj
Then, remove the first line (using DotNetWallet.KeyManagement;) from FakeData.cs file. This is an unused using statment. there are no impact to remove it.
Now, you can run dotnet restore, dotnet build then dotnet test.