using xRDP:
Source: 14.04 – Can I access Ubuntu from Windows remotely? – Ask Ubuntu
My bookmarks and blogposts regarding Software Development in .NET, C#, Angular, JavaScript, CSS, Html
using xRDP:
Source: 14.04 – Can I access Ubuntu from Windows remotely? – Ask Ubuntu
Supports .NET Core mstest, nunit and xunit tests.
Shows up under the “Explorer” side bar. (Ctrl+shift+E).
Helps you find the best NuGet packages!
Based on popularity, documentation, votes, analytics, etc
nugetmusthaves.com/
Flurl is a modern, fluent, asynchronous, testable, portable, buzzword-laden URL builder and HTTP client library.
tmenier.github.io/Flurl/
From: https://stackoverflow.com/questions/39319680/onelogin-rest-api-with-powershells-invoke-restmethod
#generic Invoke-RestMethod / WebRequest error handler #https://stackoverflow.com/questions/39319680/onelogin-rest-api-with-powershells-invoke-restmethod function Failure { $global:helpme = $body $global:helpmoref = $moref $global:result = $_.Exception.Response.GetResponseStream() $global:reader = New-Object System.IO.StreamReader($global:result) $global:responseBody = $global:reader.ReadToEnd(); Write-Host -BackgroundColor:Black -ForegroundColor:Red "Status: A system exception was caught." Write-Host -BackgroundColor:Black -ForegroundColor:Red $global:responsebody Write-Host -BackgroundColor:Black -ForegroundColor:Red "The request body has been saved to `$global:helpme" break }
Then, wrap all of your Invoke-RestMethod calls in a try Catch block like this.
try {
$e = Invoke-WebRequest 'https://api.us.onelogin.com/api/1/users/$id' `
-Headers @{ Authorization = "bearer:$token" } `
-Body ( @{ phone = "7709746046" } | ConvertTo-Json ) `
-Method Put -ErrorAction:Stop -ContentType 'application/json'
}
catch {Failure}
Now when you run into an error, you can see the actual message, like this
> Status: A system exception was caught.
{"status":{"error":true,"code":400,"type":"bad request","message":{"description":"notes is not a valid attribute for user model","attribute":"notes"}}}
The request body has been saved to $global:helpme
$x = @"
"Curiouser and curiouser!" cried Alice (she was so much surprised, that for the moment she quite forgot how to speak good English); "now I'm opening out like the largest telescope that ever was! Good-bye, feet!"
"@
$x
Source: Windows PowerShell Tip: Using Windows PowerShell “Here-Strings”
I have recently been doing custom Powershell script steps for Octopus deploy to trigger Selenium based UI tests and needed a good way to present the test outcome.
This command line tool creates a nice html dashboard page of the xml:
ReportUnit
https://github.com/reportunit/reportunit
Support for both NUnit 2.x, 3.x and MSTest
Interesting alternatives:
NUnit HTML Report Generator
https://github.com/SongArc/NUnit-HTML-Report-Generator/blob/master/README.md
NUnit Test Results Viewer
‘NUnit Test Results Viewer’ is a free open source project that allows to view NUnit resulted *xml file.
https://sourceforge.net/projects/nunittrviewer/
If tests are triggered from TeamCity or VSTS (Visual Studio Team Services) they have test report tools built-in.
From: Setting up your project and TeamCity/OctoPack for front-end builds
Octopus Deploy has a nice NuGet package, called OctoPack, for generating Octopus Deploy-compatible NuGet packages out of .NET projects.
However, OctoPack will only pack files that are included in the CSPROJ file, and in the case of static files, have Build Action set to Content. This is a problem, because this means that all files generated by your task runners, be it Gulp or Grunt, will have to be included in the project and pushed out to source control.
This introduces an unnecessary problem – conflicts in generated code. So, if developer A was working on a SCSS file which was referenced in the main stylesheet, and developer B was working on a separate SCSS file, also referenced in the same main stylesheet, why should either one have to resolve a conflict caused in the file generated by the task runner?
This makes no sense. It’s like building your .NET project, and pushing the generated DLL files to source control, and then having to resolve conflicts within the DLL files generated by the build. Why would you do that?
So, in order for you to never have to resolve another conflict in generated files again, here’s my guide on how to set up your project so they play nice with TeamCity and OctoPack.
What this does is it informs OctoPack about the files that you want to include in the deployment package. Here’s an example.
<?xml version="1.0"?> <package > <metadata> <id>MyProject.Web</id> <version>$version$</version> <authors>Geta AS</authors> <owners>Geta AS</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>MyProject.Web deployment package</description> <copyright>Copyright 2016</copyright> </metadata> <files> <file src="public\**\*.*" target="public" /> </files> </package>
As you can probably already tell, this will cause OctoPack to only include files stored in the specified folder in the generated deployment package. That’s no good.
On to the next step.
<?xml version="1.0" encoding="utf-8"?> ... <PropertyGroup> <OctoPackEnforceAddingFiles>True</OctoPackEnforceAddingFiles> </PropertyGroup> ...
This tells OctoPack to include all the files it would normally include in addition to the files specified in the NUSPEC file.
Once we have all this set up, we can commit the files, and push them to source control.
Source: Setting up your project and TeamCity/OctoPack for front-end builds