I've set up dotCover to run using an .xml
<?xml version="1.0" encoding="utf-8"?>
<CoverageParams>
<TargetExecutable>
c:\dotcover\xunit\xunit.console.exe
</TargetExecutable>
<TargetArguments>
"INWK.Configuration.UnitTests.dll"
</TargetArguments>
<TargetWorkingDir>
..\bin\x64\Debug\
</TargetWorkingDir>
<TempDir>
<!-- Directory for auxiliary files. Set to the system temp by default. -->
</TempDir>
<Output>
dotCover-xunit.dcvr
</Output>
<InheritConsole>
<!-- [True|False] Lets the application being analyzed to inherit dotCover console. True by default. -->
</InheritConsole>
</CoverageParams>
You can see (Service, Shared, UnitTests assemblies correctly included in the test coverage report (Shared, Service and UnitTest assemblies)
However, when running the same on the build server *Service and *Shared are missing.
After replacing Service.dll and Shared.dll and their "pdb's" from local copy to build server and running dotCover on build server again it works correctly.
This leads me to believe that build server runner does something different than msbuild.exe from VS when running build locally.
I found very similar issue description here: https://stackoverflow.com/questions/25855131/dotcover-and-xunit-not-gathering-coverage-statistics-in-some-environments, but not sure how to remedy this in my build server configuration.
Trace log output (one drive)
https://1drv.ms/t/s!AtxuuqGHIqXwgTVqQJ_Y_-rGE8W9?e=HrZgj7
Found the solution:
in my dotcover config xml I had to add: -noshadow switch, like so:
<CoverageParams>
<TargetExecutable>
c:\dotcover\xunit\xunit.console.exe
</TargetExecutable>
<TargetArguments>
"INWK.OrderIndexing.UnitTests.dll" -noshadow
</TargetArguments>
<TargetWorkingDir>
..\bin\x64\Release\
</TargetWorkingDir>
...
Now all assemblies (except the ones I do want to filter) are showing up
I wish to run my ASP.NET Core App by launching it from IIS Express using command line.
I stumbled across this article which says
So in fact Visual Studio silently adds the two environment variables
when launching IIS Express, so that ASP.NET Core related bits can be
injected.
LAUNCHER_ARGS: -debug -p “C:\Program Files\dotnet\dotnet.exe” -a “exec
\”C:\Users\lextm\documents\visual studio
2017\Projects\WebApplication2\WebApplication2\bin\Debug\netcoreapp1.0\WebApplication2.dll\””
-pidFile “C:\Users\lextm\AppData\Local\Temp\2\tmpFD6D.tmp” -wd “C:\Users\lextm\documents\visual studio
2017\Projects\WebApplication2\WebApplication2”
The tmp file in -pidFile “C:\Users\lextm\AppData\Local\Temp\2\tmpFD6D.tmp” can always change. How do I add LAUNCHER_ARGS as environment variable which will make it work even if the tmp file changes?
Let me know if there is any easier way to launch IIS Express to run ASP.NET Core Apps with command line or powershell scripts.
You are looking for [System.IO.Path]::GetTempFileName() method. It creates empty temp file on file system and returns its unique name.
I'm currently using the following PowerShell script to run my .NET Core 2.0 App:
$env:LAUNCHER_ARGS = "-p ""<path to dotnet.exe>"" -a ""exec \""<path to webapp main dll>\"""" -pidFile $([System.IO.Path]::GetTempFileName()) -wd ""<path to webapp root folder>"" -pr <project name>"
$env:LAUNCHER_PATH = "<path to VSIISExeLauncher.exe>"
& "<path to iisexpress.exe>" /config:"<path to applicationhost.config>" /site:"<webapp name>"
Placeholders (text within angle brackets) have to be filled with the corresponding values. You can find them out by running your project from Visual Studio and inspecting environment variables of iisexpress.exe process using Process Explorer as shown above in the link you provided.
In .NET Core 3 the solution to this problem has changed. Follow these steps.
1) The environment variables should now be:
LAUNCHER_ARGS=exec "C:\YourWebApiProject\bin\Debug\netcoreapp3.1\YourWebApiProject.dll"
LAUNCHER_PATH=C:\Program Files\dotnet\dotnet.exe
Change the first path to your dll path and ensure the .NET version in the path is correct. Note that there is no longer a need to create a temp file.
2) Ensure that both modules AspNetCoreModule and AspNetCoreModuleV2 are registered in the file .vs\{your solution name}\config\applicationhost.config as follows:
Under <system.webServer> <globalModules> add:
<add name="AspNetCoreModule" image="%IIS_BIN%\aspnetcore.dll" />
<add name="AspNetCoreModuleV2" image="%IIS_BIN%\Asp.Net Core Module\V2\aspnetcorev2.dll" />
Under <sectionGroup name="system.webServer"> add:
<section name="aspNetCore" overrideModeDefault="Allow" />
Under <location path="" overrideMode="Allow"> <system.webServer> <modules> add:
<add name="AspNetCoreModule" lockItem="true" />
<add name="AspNetCoreModuleV2" lockItem="true" />
It's also a good idea to make this change to the templates for this file which are located at %PROGRAMFILES%\IIS Express\config\templates\PersonalWebServer\applicationhost.config and %PROGRAMFILES(x86)%\IIS Express\config\templates\PersonalWebServer\applicationhost.config so that new VS solutions you create automatically get these changes to their configs. (Credit to this post)
3) Be mindful of whether you're using 32 or 64 bit IIS Express. (If you're on a 64 bit machine then 32 bit IIS Express = C:\Program Files (x86)\IIS Express, 64 bit = C:\Program Files\IIS Express) In my case, 32 bit had worked fine previously but after migrating to .NET Core 3 I had to use 64 bit or else the above modules wouldn't load.
I needed to run multiple .Net Core API endpoints at a time easily without popping open Visual Studio for each and every one of them. I ended up using answers here to build the following:
iisaspnet.bat:
#echo off
:: Args are like:
:: MobileApi
:: C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src\HCPMobileApi
:: MobileApi\bin\Debug\netcoreapp2.2\MobileApi.dll
:: .vs\MobileApp\config\applicationhost.config
setlocal
set PATH=%PATH%;C:\Program Files\IIS Express
set LAUNCHER_ARGS=exec %2\%3
set LAUNCHER_PATH=C:\Program Files\dotnet\dotnet.exe
iisexpress /site:%1 /config:"%2\%4"
:: Comment out line below to check for errors
exit
The first arg is the name of the Project - the name in Visual Studio (in some scenarios people go rogue and name their Project file one thing and the Project itself another thing - you want the Project name, not the file name, in this scenario).
The second arg is the root folder for third and fourth args.
The third arg is where to find the compiled Project DLL
The fourth arg is where to find the applicationhost.config that explains how to launch the site. As you'll see below, this is generally found in your .vs folder, but, where this exists can get a little crazy depending on how creative people get with organizing their Solution and Project folders. Generally the .vs folder is going to sit in the same folder as the .sln file, so it may be far from the Project folder/files.
This will be less helpful, but here's the batch file that kicks off the IIS Express windows, so you can see iisaspnet.bat in use:
start iisaspnet.bat MobileApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src\HCPMobileApi MobileApi\bin\Debug\netcoreapp2.2\MobileApi.dll .vs\MobileApp\config\applicationhost.config
start iisaspnet.bat HCP.MasterDataApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src MasterData\Api\HCP.MasterDataApi\bin\Debug\netcoreapp2.2\HCP.MasterDataApi.dll Solutions\.vs\MasterData\config\applicationhost.config
start iisaspnet.bat HCP.SecurityApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src Security\Api\HCP.SecurityApi\bin\Debug\netcoreapp2.2\HCP.SecurityApi.dll Solutions\.vs\Security\config\applicationhost.config
start iisaspnet.bat HCP.BillingApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src Billing\Api\HCP.BillingApi\bin\Debug\netcoreapp2.2\HCP.BillingApi.dll Solutions\.vs\Billing\config\applicationhost.config
start iisaspnet.bat HCP.ClientApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src Client\Api\HCP.ClientApi\bin\Debug\netcoreapp2.2\HCP.ClientApi.dll Solutions\.vs\Client\config\applicationhost.config
start iisaspnet.bat HCP.EmployeeApi C:\Users\chris\Dropbox\Code\2017\VbaMeasureHcp\src Employee\Api\HCP.EmployeeApi\bin\Debug\netcoreapp2.2\HCP.EmployeeApi.dll Solutions\.vs\Employee\config\applicationhost.config
The way the parameters work could likely be far simpler if the way the Projects, Solutions, etc were stored and named was more consistent, but, this is an existing set of Solutions I had no control over with scattered naming etc, and, the chaos above may be more helpful anyway for understanding how to call these commands.
The result is that running one command kicks off 6 IIS Express command windows for me, requests get logged to each of their windows, and I just type Q in each window to kill them.
I have a TFS 2013 build that I'm trying to get to publish to a folder on the build server. I've installed WebDeploy, but I always get the error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (4274): Web deployment task failed. (Could not connect to the remote computer ("localhost"). On the remote computer, make sure that Web Deploy is installed and that the required process ("Web Management Service") is started. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.)
I've set up a website on the build server and that's where I'm trying to publish the website. Actually I don't even care about publishing it per se - I just need my build output to go to a folder locally automatically. Right now we have to manually open the solution and choose Publish... to get the output that subsequent InstallShield builds need for input. Here are my MSBuild arguments. Does anyone have any idea what could be missing?
/p:SrcDir=C:\Builds\TFS\WebApps\Src
/p:RevKeyname=WebAppsRevNr
/p:DeployOnBuild=true
/p:DeployTarget=MsDeployPublish
/p:MSDeployServiceURL=https://127.0.0.1:8172/msdeploy.axd
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath="WebApp"
/p:MsDeployPublishMethod=WMSVC
/p:AllowUntrustedCertificate=True
/p:AutoParameterizationWebConfigConnectionStrings=False
/p:Authtype=NTLM /p:username=""
I've checked both net start wmsvc and net start msdepsvc and both are running. Any ideas?
Thanks!
UPDATE
I've tried everything that Andy suggested and now when I run this from the command line I get this bizarre error message:
"C:\Workspace\VS2013\WebApps\Main\Src\webapps.sln" (default target) (1) ->
"C:\Workspace\VS2013\WebApps\Main\Src\CoreWebApps\CoreWebApps.csproj"
(default
target) (7) ->
(AutoParameterizationWebConfigConnectionStringsCore target) ->
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web
.Publishing.targets(2295,5): error : Could not open Source file: Could not
find
a part of the path
'C:\Workspace\VS2013\WebApps\Main\Src\CoreWebApps\Areas\Adm
in\Views\Web.config;Areas\Admin\Views\Web.config'.
[C:\Workspace\VS2013\WebApps
\Main\Src\CoreWebApps\CoreWebApps.csproj]
Any idea why it's looking for Web.config;Areas\Admin\Views\Web.config'.? That makes no sense.
Please try below items to narrow down the issue:
Try to use IP or Machine Name instead of "localhost"
Logon your build agent machine, then manually execute the same
MSBuild command within the same arguments(which you provided in build
definition) to build and deploy your solution, then check result. You
need to ensure you can manually run the same MSBuild command within
deploy argument to build and deploy your solution successfully from
build agent machine. Then use the same deploy arguments in TFS Build
definition.
Double check Web Deploy settings to make sure that the name of the
website is exactly that of what's in IIS.
Install Web Management Tools before Web
Deploy : Install the Web Management Services (Roles -> Web Server >
Management Tools > Management Services). Then uninstall Web Deploy, and then install Web Deploy again.
You can also reference this thread for your troubleshooting.
Update:
For the issue "Could not open Source file: Could not find a part of the path" you can reference below similar articles for the troubleshooting.
https://social.msdn.microsoft.com/Forums/en-US/8f959964-c951-4f9a-8486-8283a925c9f6/build-error-could-not-open-source-file-though-i-know-it-exists?forum=windowsazurewebsitespreview
https://our.umbraco.org/forum/getting-started/installing-umbraco/60222-Umbraco-721-Build-fails-after-deploy-to-Azure-WebSite (See the last two answers)
I am unable to install/restore nuget packages from a Visual Studio Team Services feed in an asp.net core web application (RC2). I receive the following:
error: Response status code does not indicate success: 401
(Unauthorized).
I am running Visual Studio Community 2015 Update 2 and nuget version 3.4.4. I am able to install/restore packages from this feed in other project types.
Do I need to do something else to pass my credentials for an asp.net core web app?
Steps to reproduce:
From Team Services package tab I select "Connect to Feed" and copy the NuGet package source URL
In visual studio -> Tools -> NuGet Package Manager -> Package Manager settings -> Package sources and add the feed url from vso
Then from my ASP.NET Core Web Application (.NET Framework) project right click references -> Manage NuGet Packages
-> Select my feed from Package source (packages are listed) -> Click to install
In output:
Installing NuGet package xxxxx
Successfully installed xxxxx to WebApplication1
========== Finished ==========
Then it will try to restore the package at which point I get:
error: Response status code does not indicate success: 401 (Unauthorized).
error: Failed to retrieve information from remote source
And inside web project references - package has warning icon - NU1001 The dependency xxxxx could not be resolved
I know that it's not exactly the same issue, but people may come across this one alongside as I did.
I have installed VS Community 2019 and yesterday I decided to remove the VS 2017, but after that, when I tried to restore the Nuget Packages made by the company, it started displaying an error of 401 Unauthorized.
After a few net searches I decided I didn't want to mess around with VS configurations and files, I then realized, since it's an 401 Unauthorized it's related with an account so what I did was:
Closed VS2019
Went to windows management credentials and removed all those that where related with my packages
Reopened VS 2019 and restored the Nuget Packages for my solution.
It them asked for my credentials, set it up and all went well from here.
Here are the two accounts I removed and got recreated:
In my case I was using an azure dev ops feed. After updating visual studio 2022 I started getting this message "Response status code does not indicate success: 401 (Unauthorized)."
I followed and tried most of the solutions here. but what worked for me was to
Go to: file -> accounts settings
Click "sign out"
Then go to the nuget manager and click the refresh button
This will then show you the azure dev ops login window where you login to your account
This worked for me, (your mileage may vary) just hope it helps someone else and saves some precious receding hairs.
I can reproduce your issue at my side and following is the workaround I use to restore the packages:
Remove the VSTS feed resource from "VS\Tools\NuGet Package Manager\Package sources".
Open "Packages" tab from your VSTS web portal.
Select the feed you want to connect and click "Connect to feed" option.
Select "Personal Access Tokens" method in the dialog.
Copy the generated command in the dialog.
Run CMD as Administrator on you machine.
Paste the copied command into CMD.
Add "-StorePasswordInClearText" argument after the command.
Run the command.
Restart the VS.
Install and restore the packages.
For me, the issue was due to incorrect credentials (not specifying the domain) when connecting to a private on-premise Azure Artifacts NuGet feed, which wasn't immediately apparent.
Using Visual Studio 2019, open NuGet Package Manager for a project. If the 'Browse' tab shows first and the package source is the private NuGet feed, there appears to be no issue as it initially lists all packages. However, switching to the 'Installed' tab results in a login dialogue popping up.
If I enter my username and password without the domain (so username intead of domain/username), it appears to accept this, but then no other versions are listed for my installed packages other than the version installed. If I go to the 'Browse' tab, I then see the following error:
When I click 'Show errors in output', I see the following:
Failed to retrieve metadata from source 'https://[domain]/[Collection]/_packaging/[GUID]/nuget/v3/query2/?q=&skip=0&take=26&prerelease=true&semVerLevel=2.0.0'.
Response status code does not indicate success: 401 (Unauthorized).
To resolve this, in Credential Manager, I close Visual Studio, then remove any credentials relating to the Azure DevOps server(e.g., [domain], VSCredentials_[domain]). I noticed that the username for these showed the wrong domain - it showed the Azure DevOps server domain instead of the Active Directory domain.
I then reopen Visual Studio, open NuGet Package Manager again and this time (on the 'Installed' tab) enter my credentials including the domain (domain/username). This resolves the issue and allows me to connect to the Azure Artifact NuGet feed.
This happens when you change your profile password. Just sign out and from top right (at your profile picture-> account settings); sign in again and your problem will be solved.
I had a similar problem (no authentication) in the NuGet Restore task of a VSTS build definition. The solution was to add a NuGet.config file in the root of the project with a reference to the official and my custom feed. Maybe it helps your core project also.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="RmlrTools" value="https://<MyProjectName>.pkgs.visualstudio.com/DefaultCollection/_packaging/<MyFeedName>/nuget/v3/index.json" />
</packageSources>
<!-- used to store credentials -->
<packageSourceCredentials />
<!-- Used to specify which one of the sources are active -->
<activePackageSource>
<!-- this tells only one given source is active -->
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<!-- this tells that all of them are active -->
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<!-- Used to disable package sources -->
<disabledPackageSources />
<!--
Used to specify default API key associated with sources.
See: NuGet.exe help setApiKey
See: NuGet.exe help push
See: NuGet.exe help mirror
-->
<!--<apikeys>
<add key="http://MyRepo/ES/api/v2/package" value="encrypted_api_key" />
</apikeys>-->
</configuration>
Try restarting the computer before you try any of the above.
In my case , I followed these steps
create the personal access token with relevant credentials
download nuget.exe (nuget cli)
using windows run command open the cmd,then
cd C:\Downloads(where the cli is downloaded) ,type
"nuget.exe" and enter
execute -->
nuget.exe sources Add -Name "MyFeedName" -Source "https://myfeedurl" -username username -password MyAccessToken
in visual studio tools->commandline->developer command prompt
dotnet restore
Go to "Manage Nuget Packages"
Click "Setting" from right top Corner
Untick "Packages"
In my case I was using Azure Devops private feed and the NuGet package restoring worked in Visual Studio and in Nuget CLI but it didn't work with Rider and dotnet restore command
The solution was to install The Azure Artifacts Credential Provider and it fixed the problem. I just had to run this command to install it:
iex "& { $(irm https://aka.ms/install-artifacts-credprovider.ps1) }"
This is a fix for a local developer machine. For fixing it on CI/CD check this question.
I'm using VS 2022. The way I was able to fix it is to relog into VS. The trick is the tooltip on the top right SAYS I'm logged in, but when you click your profile logo on the top right, then goto Account Settings, it told me I needed to "reenter my credentials". How does that work, I'm logged in, but I'm not logged in? Turns out it doesn't work, I needed to log in AGAIN for it to REALLY work.
I am trying to install a windows service using MSBuild and CCNET. I am using MSBuild Extension pack WindowsService
task to install and start the windows service as part of automated build. The script section look like this
<!--install service-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Install" ServiceName="$(PrServiceName)" ServicePath="$(PrServicePath)" User="$(User)" />
<!--set service to run automatically on restart-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="SetAutomatic" ServiceName="$(PrServiceName)" />
<!--start service-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Start" ServiceName="$(PrServiceName)" ServicePath="$(PrServicePath)" User="$(User)" />
Now as soon as the the first task runs to install the service, it fails with the following error
E:\Data\cc_temp\Projects\cubic\intranet\pr\pr.build (137,3): error : Install Service failed with code: 'AccessDenied'
I assume this is because the script is running under cruise control service user account which does not have the appropriate permissions for installing a windows service.
I would just like to give minimal permissions to the cruise control user account instead of giving the full administrative rights.
Does anyone out there knows how can i achieve this?
Awaiting
Nabeel
Nabeel you are on the right track, it has to be a permissions issue. We do this all the time in our build using the same tools and it works. Have you checked to see which account the service is running as? and using the same user account to run your cruisecontrol? at least then you would possibly prove/disprove the permissions issue.