I have two Asp.Net Core projects - one is version 2.2. and one is version 3.0.
Each project is a brand new, empty MVC project created in Visual Studio.
I run each project by dropping to the command line and doing dotnet run.
I then debug my code as follows:
Open Task Manager and find the process Id for the dotnet process
Doing Debug -> Attach to Process in Visual Studio 2019
For the version 2.2 project, I can easily identify the correct dotnet process in Task Manager - it's the one showing the dotnet exec command pointing to my project's .dll file:
However - for the 3.0 project, the dotnet processes in Task Manager look like this:
None of the processes is clearly associated with my project's .dll files, and none of them allows me to debug my code using Attach to Process.
So my question is - is there a way of attaching Visual Studio's debugger to an Asp.Net Core 3.0 project when I run it using dotnet run ?
I had the same issue after upgrading a ASP.NET Core 2.2 project to ASP.NET Core 3.0. I have used a trick to find out the process I should attach to whenever needed:
Run with Debug (F5)
Attach to Process
Find the process which is grayed out (already attached). This is the process that should be used to further process attachments
In my case the process was called {AssemblyName}.exe.
Side note: You can find Reattach extension particularly useful for quickly reattaching (e.g. Ctrl-R Ctrl-1) to previous processes.
Turns out that the Asp.Net Core 3.0 project, when run using dotnet run, has a different entry in Task Manager than 2.2 - the .exe file produced by the build is what is displayed in Task Manager's details, and I can successfully attach to this process in Visual Studio:
Related
I've created an ASP.NET core 2.1 project in VS2017 and run it successfully from VS2017.
The question is, What is the easiest way to run the above configuration (not production/release/deploy configuration) out of Visual Studio, on the same machine.
I can't find any exe in the project, and dotnet run in the project folder/output folder doesn't work.
It's best to generate an exe and click it to run.
It requires a lot of preparations to run kestrel as standalone application. Checkout this sample implementation in GitHub
https://github.com/PeteX/StandaloneKestrel
I try publish ASP .NET Core2 app.
App is work in visual studio 2017
dotnet build -c Release completed without error
dotnet publish -c Release
Has error
Cannot find compilation library location for package 'Hangfire.MemoryStorage'
But Hangfire.MemoryStorage is _Libs\Hangfire.MemoryStorage.dll not a package
build compiles all your .cs files mainly
publish also compiles all your view files into a single .dll file. So it validates your views as well.
So, If you have an error only in the publish and not in the build, there most probably must be a bug somewhere in your views. Even if the app worked in visual studio, there might be a run time issue somewhere if the bug is in a view.
Regarding the Hangfire.MemoryStorage library. The last update was three months ago. There have also been past issues with this library related to the code not updated for the latest version of .net core. So, I don't think he has released the stable version for .net core 2.0 yet (assuming you have the latest version of the app installed).
My infrastructure now has TFS 2015, but we started a new project in .NET Standard. Our build server now has VS2017, and the project builds when loaded within VS2017 in that server.
When we set a new build definition to run the build through the build agent, then it fails. Seems even that System is not found:
Error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
Is there any simple thing to do to make it work, ir we will have to migrate to the new build steps to make it work? Some workaround?
I find a workaround for that. Simply I gave up of using the TFS 2015 build steps MSBUILD and Visual Studio Build, and now I am using the Command Line step. Calling the commands from there:
dotnet restore
dotnet build
That does the trick.
This is because we need to do our restore a different way using the .net core restore. You could fix this by adding the .NET Core (PREVIEW) task to the build definition or just use command line task. With command line task could running dotnet restore, dotnet build, dotnet publish, and dotnet test.
More details please take a look at this blog: Setting up .net core continuous integration build with VSTS/TFS
For command line solution please refer vsts-agent Build Definition for .NET Core (with Test Results) Also take a look at this similar question: Visual studio team services build .net core 1.1
I've updated my app from DNX, ASP.NET 5 RC1 to ASP.NET Core 1.0 RC2.
Locally it builds and runs fine.
On the build server, I don't have Visual Studio installed, and the build fails with:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\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 did install the: .NET Core SDK for Windows.
Trying to install the VS 2015 tooling preview fails with:
What would be the correct setup to build .NET Core 1.0 RC2 app on the build server without having to install Visual Studio 2015?
Note: The build box (TeamCity 9) builds/runs tests fine for .NET 4.5 and DNX.
https://learn.microsoft.com/en-us/dotnet/articles/core/windows-prerequisites#issues
Issues
You may be blocked from installing the .NET Core Tooling Preview 2 for Visual Studio 2015 installer due to a temporary bug. To workaround it, run the installer from the commandline with the SKIP_VSU_CHECK=1 argument, as you see in the example below.
DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1
I'm able to build the solution now. Still can't publish though.
I just copied all the new MSBuild stuff to the build server. I copied:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\
From my local computer to the build server. That includes the new DotNet sub-folder, which contains:
Microsoft.DotNet.Common.targets
Microsoft.DotNet.Extensions.targets
Microsoft.DotNet.props
Microsoft.DotNet.Publishing.targets
Microsoft.DotNet.targets
Microsoft.DotNet.Tasks.dll
Microsoft.VisualStudio.ProjectSystem.DotNet.Runtime.dll
Newtonsoft.Json.dll
I can build the Solution (without the publish arguments) it fails when I try:
MSBuild.exe Solution.sln /p:DeployOnBuild=true /p:publishprofile=local
You can build and test you project via the command line - so there is no need to have Visual Studio installed. By using build steps of type "Command Line" you can run: dotnet restore, dotnet build, dotnet test
Here you can find some description how to run that as a build on TFS. It is written for the hosted TFS but works on-premise as well (and is not only meant for azure as the name of the document might imply):
https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnetcore-to-azure
For the pubsishing I have used msdeploy with RC1 but have not yet migrated my deployment build. I might document it here when this is done within the next days.
So without Visual Studio or Web Deploy, my TeamCity build is comprised of 4 builds steps:
dotnet restore
dotnet build
dotnet test
dotnet publish -c Release
I run dotnet test on all projects with a basic for loop.
We're trying to work through the new tool chain for building and deploying an ASP.NET 5 (vNext) CoreCLR web site to a server cluster. Between the new compilation changes and the changes to TFS, I'm not sure how everything now gets built and deployed. The scenario is as follows:
On-premise TFS for source control and build agent
Targeting ASP.NET 5 under CoreCLR, hosted via IIS
Questions are:
Using TFS for continuous integration builds (and hopefully deployment to an on-premise IIS server), how does one build and deploy this new application type?
It seems like MSBuild might still be usable to point at a .sln file so as to indirectly invoke dnu.exe, is that correct? Is that the appropriate way to do that now?
Should we be running a scripted build task instead to run dnu.exe instead?
How are these new CoreCLR builds deployed? Just a straight copy to a directory on a remote machine?
This is a new application and we're using a multi-layered application architecture, where the DAL and Business logic are in their own CoreCLR projects, if that makes a difference.
Thanks in advance for shedding some light on the situation.
Here is what we ended up doing:
Powershell script "prebuild.ps1" as per the previous answer and Microsoft deployment guidelines: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5
Vanilla MSBuild build. no switches or special settings.
Powershell script to execute xUnit test runner. We used guidance from this post at http://fluentbytes.com/running-xunit-test-with-asp-net-dnx-and-tfs-2015-build/
Powershell script to run "dnu publish". This creates a directory of the entire web application's structure.
"Windows File Copy" task to deploy the directory structure created in #4 to all of the target machines in the test environment.
To build and deploy ASP.NET 5 via TFS2015 vNext build system, you need to:
1). Create a PowerShell script (named Prebuild.ps1, for example) to install DNX. Details of the PowerShell script can be found: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5 . Add the script file into TFS version control.
2). Add the PowerShell script build step into build definition. Run the Prebuild.ps1 script in this step:
3). In the MSBuild step, specify the project needs to be built, and add the following /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MsDeployServiceUrl=localhost /p:DeployIisAppPath="Default Web Site/TFSTest1" /p:VisualStudioVersion=14.0 to publish the project to IIS.