I cannot seem to deploy my WPF app using the Rider IDE. Most support tell me to use the "Publish" button in VS which of course doesn't really help me.
I do produce an executable with the .NET Project and .NET Executable build Configurations, but it doesn't seem to run on any other machine, where it seems to close immediately without spitting error messages (even from PowerShell)
N.B. the app launches fine from my own machine, and from anywhere I choose to move it to.
I've tried to set Edit Configurations... > Runtime arguments: to
dotnet publish -c Release -r win10-x64
as suggested in this post, but that wasn't enough.
Running dotnet publish -c Release -r win10-x64 .\my_app.csproj from PowerShell returns
error MSB4216: Impossible to execute the task "GenerateResource"
[...]
Failed to connect to "CLR4" runtime and the "x86" architecture.
Make sure that
(1) The necessary runtime and/or architecture is present on the machine
(2) "C:\Program Files\dotnet\sdk\<version>\MSBuild.exe" exists and
has permissions to execute.
Now MSBuild is missing from that folder, but there is MSBuild.dll there.
Am I really missing a fool-proof easy way of publishing a C# WPF solution with Rider?
I use https://wixtoolset.org/ to publish my apps. It's free and independent of the IDE...
Related
I am using Visual Studio Community 2022, and I was wondering if you could use another CLI to run/debug a c# console application. (I can't use cmd.exe or powershell because it's blocked by the admins of the device I'm using). Git Bash would be preferred, because it's already installed. Thank you!
Edit: Looks like you can't do this. dotnet run just tries to open the blocked binary, no matter where you run it. I think the admins hate everyone though because they allow you to install lots of things (like Unity, vscode, etc.) but running anything just doesn't work.
Thanks for trying everyone!
use this to run your program in CLI but you cannot debug it if you want to debug use debugger mode of vs2022,
If it's a framework-dependent application (the default), you run it by dotnet yourapp.dll.
Run the project in the current directory:
dotnet run
check Microsoft Docs dotnet run for more options.
CLI: Use Vs2022 Terminal in View->Terminal it may help You to run it.
I have an ASP.NET Core 5 project that as the main function runs a typical ASP.NET web project. So typically I start it with dotnet watch run and the server runs in the background continuously. But I'm also trying to add a way to execute console commands to the same executable, which reuse the code from the server version but don't start the actual WebHost from ASP.NET. The command line version should be able to run either with the server version already running, or entirely standalone.
The problem now is that I'm quite obviously doing something that dotnet run wasn't meant for, because the build is extremely flaky and fails quite often with unhelpful errors (e.g. file access errors, . It does make sense that running dotnet run again while it's still running in the background isn't a supported case, so I'm trying to find a different way to do this.
The whole thing runs inside Docker, though this probably doesn't change anything for my specific problem. I'm using VS Code, so Visual Studio specific solutions would not work for me, it must run with the dotnet CLI alone.
What I want to do is to have a dotnet watch run in the background during development, and a way to just execute the binary it built separately without triggering a simultaneous build that leads to problems. At least as far as I can tell this should avoid the issues I've been running into, if I'm wrong here and running simultaneous dotnet run or dotnet watch run should not cause build issues, please correct me here. I assume that running a separate dotnet build would run into the same issues, and I could not see anything in the dotnet CLI documentation that would fit my use case.
How can I safely run my project in development a second time while it is still running via dotnet watch run in the background?
A quick workaround is to use different build configurations (i.e. dotnet watch run -c Debug and dotnet run -c Release). If you haven't overridden the default output directory (./bin/<configuration>/<framework>/), you will be effectively using two compiled versions of the application, avoiding those 'flaky builds'.
You could also create your own build configuration for this purpose (i.e. dotnet run -c My_Debug) and configure it to have 'debug' properties, avoiding having to use the default Release configuration.
I'm facing the issue that a .Net Core WPF application automatically opens a console window when started. This only happens when build inside a Docker container. When I build it directly on my PC, only the actual application window opens.
My best guess is that this is an issue with the operating system the .Net Core image is based on. The .Net Core SDK Docker Hub Repo knows the following tags: 3.1-nanoserver-1809, 3.1-nanoserver-1903, 3.1-nanoserver-1909, 3.1-nanoserver-2004, 3.1-nanoserver-2009. I was able to confirm the issue with the first three tags, but the 2004 and 2009 tags do not run on my machine, so I need someone to try this out and either confirm my theory (which would mean that it should not happen on at least on of these images) or to come up with a better explanation of why this is happening.
This is reproducible with the default .Net Core WPF app Visual Studio creates for you. Here is a Dockerfile to test it out:
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY . ./
RUN dotnet build -c Debug -o out
FROM stefanscherer/chocolatey
WORKDIR /app
RUN choco install -y 7zip
# Depending on your project setup it might be src/[project name]/out
COPY --from=build /src/out ./test
RUN 7z a -y test.zip ./test/*
You can build the image and extract the compiled program with the following commands:
docker build -t testimage .
docker run -d --name testcontainer testimage
docker stop testcontainer
docker cp testcontainer:app/test.zip .
I was able to reproduce this problem on both 3.1-nanoserver-2009 and 3.1-nanoserver-2004 for you.
I think the problem is related to the warning printed out during build:
warning NETSDK1074: The application host executable will not be customized because adding resources requires that the build be performed on Windows (excluding Nano Server).
If that's the case, then it seems that it is a limitation of the nanoserver base image, and unfortunately it looks like this problem still has not been resolved, because it's still present when building in mcr.microsoft.com/dotnet/nightly/sdk:5.0.
Here's a related pull request that might shed some light on the subject.
Having said that, I think the only option for now is to use windows image other than nanoserver (alternatives can be found here). I didn't find any image that would come with .NET Core SDK preinstalled (I didn't put much effort into finding it though), but it should be fairly simple to set it up. In the following example I used servercore image since it is much more lightweight than windows image.
FROM mcr.microsoft.com/windows/servercore:20H2 AS sdk
WORKDIR /dotnet
# Download the official .NET Core install script
RUN powershell -c "Invoke-WebRequest -Uri https://dot.net/v1/dotnet-install.ps1 -OutFile dotnet-install.ps1"
# Run the install script
RUN powershell -c "& ./dotnet-install.ps1 -InstallDir ."
# Add the installed executable to PATH
RUN setx PATH "%PATH%;/dotnet"
FROM sdk AS build
# Do your stuff here
Here you'll find the documentation for the install script.
I also did confirm that the produced application did not spawn console window when run.
As #Grx70 mentioned, the underlying nanoserver image is the problem.
There is another .NET core image, but it is based on the servercore image.
This saves the manual installation of .NET Core within the image and has everything ready at hand.
Here you can find all version of the .NET Core Image:
DockerHub
Way down at the bottom, you'll find the heading Windows Server Core 2019 amd64 Tags and the associated mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019 image.
This image no longer produced a console window when I built something :)
I'm trying to run a .NET Core 3 executable on a 64-bit ARM machine. The Pine64 to be exact. I'm running the executable on 16.04 Ubuntu and using the linux-arm RID and it builds just fine but when trying to run it I get the error No such file or directory even though I'm looking at the file right in front of me.
Here is the command I'm running:
dotnet publish -c release -r linux-arm /p:PublishSingleFile=true -o $CWD/binaries/linux-arm -v q
If I build it without the single file then it runs perfectly fine but I need it to be a single file executable.
Any help is greatly appreciated!
I believe I found the answer. So I was using the RID linux-arm which is fine if you are using a 32-bit device like a RaspberryPi. Pine64 is a 64-bit device and I was under the assumption that linux-arm was a magical RID that did both 64 and 32-bit because the Microsoft docs made it out that it was just that easy (at least that's how I interpreted it). Anyways, I used linux-arm64 and BOOM it worked.
I wrote a console app in C# on VS 2017 for mac, and the resulting build file is a .dll. I can run that fine in the IDE and from the terminal with "dotnet blah.dll".
What I really want is to give my little console app to my Windows friends who can then run it.
I'm not finding detail on the web or here on how to tell VS2017 mac to make me a Windows exe.
There is a framework-dependent deployment assuming your friends have .net core runtime, they can also run with "dotnet blah.dll"
Otherwise you need to configure self-contained deployment using dotnet publish -c release -r win10-x64 command and some project configuration. More details are available at dotnet publish MSDN article and deployment strategies overall
You need to have a runtime identifier in your csproj for Windows in order for a Windows-compatible binary to be generated. Similar for various Linux distributions.
A list of IDs can be found at: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog. For example, to target Windows 10 x64 you would use win10-x64.
Once you have the csproj configured and have rebuilt you should see a win10-x64 folder in your build output that will contain the files you need.