He have configured NuGet to run as part of the solution, but we have issues with configuration. It seems to only pick the local configuration file from %APPDATA%\..., which is the opposite to what we want it to do (use the config from the version control system, stored with the code). How can I figure out what exactly NuGet is doing when run during the build in Visual Studio? Is there an option for a verbose run, so that it dumps all the paths that it is using, etc.?
you can try to build the solution using msbuild:
"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" abcd.sln /t:Build /property:Configuration=Release /v:diag
Related
For the software at work we have multiple projects in a solution. Most of the project we can just build the solution and then publish artifacts of the web project that we need. API and Auth projects are slightly different though. Our currently deployment process is manual and for the API (STARS.API.csproj) and Auth (STARS.Auth.csproj) project when would go into Visual Studio 2017 and right click the project and click publish, select a profile and then publish. Once that is done we take the Publish Output and drop those files on our server.
We are trying to move to a automated process through TFS and I am using the Visual Studio Build task in a build definition. However when I try to run this through TFS, an error saying that the publish profile cannot be found:
Validating PublishProfile(TFSProfile.pubxml) settings. C:\Program
Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets(4368,5):
Error : The value for PublishProfile is set to 'TFSProfile.pubxml',
expected to find the file at
'C:\agent_work\4\s\STARS\Source-dev\STARS.Web\Properties\PublishProfiles\TFSProfile.pubxml'
but it could not be found.
It is looking for publish profile in a different project folder.
Visual Studio Build Task:
I feel that I can approaching this completely wrong. I am just trying to replicate the process on publishing the project through Visual Studio 2017 manually.
Please let me know if you require more information.
I suggest you start using the pre-defined build variables. $(Build.SourcesDirectory) will map to C:\agent_work\4\s, and from there you can create a full path to the TFSProfile.pubxml, where ever it might be in your source tree. Use this full path in the MB Build Arguments, PublishProfile property, e.g.
/p:PublishProfile=$(Build.SourcesDirectory)\STARS\Source-dev\STARS-API\TFSProfile.pubxml
Another problem you may have is that in the Solution field you are not specifying a solution (.sln) but a project (.csproj). I suspect that MSBuild is picking up the solution associated with that csproj, and building the whole solution, which is why it is looking for a publish profile in STARS.Web. Have you created a publish profile for STARS.API?
I have a solution in Visual Studio 2015 that uses several NuGet packages. When I build in Visual Studio 2015, the packages are restored properly and the build succeeds. However, when I push that same project to Visual Studio Online, even though I have "Restore NuGet Packages" checked, the build fails because MSBuild cannot find the referenced binary.
I have looked at the build log and see that my packages are all being restored. Why, even though the package is restored, is the referenced binary not found during the build?
I found that the problem was not in the NuGet package restore, but in the way that the hint path was written in my .csproj file. To the fix the problem, change the hint path to point to the solution directory using the $(SolutionDir) variable.
For example, the NuGet restore pulled the Microsoft.WindowsAzure.Storage.dll binary, but it could not be found on the build of the project. To fix this, I had to open the .csproj, find the reference to the dll, and change the path from
..\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
-- to --
$(SolutionDir)\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
By using the $(SolutionDir) variable, Visual Studio Team Services was able to find my referenced dll and build my project properly.
You might also consider checking if the file packages.config, which surely resides on you local system, also gets checked in and is under version control.
First, you might want to see if it's present at the build server (image below is from VS Team Services but it's the same general idea in on-site environment.
Secondly, verify that the file's under version control. As a test, see if it appears under Pending Changes if you add a package.
I made a project with a working build start to fail when I added nUnit. Then, as I checked in the package.config file, it started to restore the packages on the server. When I removed the file from the server, the builds starter to fail again. Details are described in this post.
I'm putting together a new stack of unit tests to be run together as a CI job. I'm using vstest.console.exe instead of mstest.exe mainly for its ability to run tests from several frameworks, but right now the focus is a few xUnit dlls. The jobs are run as part of a Jenkins pipeline.
I have tested everything successfully on a couple of dev boxes, but annoyingly test discovery is not working on any of the CI build boxes so far. This is after the addition of the 0.99.8 xUnit test adapter vsix (also tested with 0.99.7). The xUnit dlls are being built against 4.5 with the 2.0.0.2378 beta nuget version of xUnit.
I have reproduced the symptoms with the simplest possible dll, with a single public test method, working fine on my own box, not working on any build boxes. The deployment enviroment is pretty straight forward, with a VS2012 install and the xUnit test adapter, on Windows 2012.
I have enabled the TpTrace logging via the vstest exe config files and everything looks fine. I guess I'm looking for a way to troubleshoot the issue further (maybe tracing for the xUnit discovery process) or a workaround the problem. I'd prefer to retain the use of vstest console for the simplicity of running several frameworks.
I have written up this issue via the xUnit codeplex site as well.
I've checked out this SO post but none of the suggested solutions make sense here.
It takes me quite some time to find the solution of how to use vstest.console.exe and xunit for VS2013, so I think it worth the time to explain here how I did for everyone...
The first step is to follow what is explained here to install the pre-release xunit.runner.visualstudio nuget package in the xunit projects that need it to be able to run the xunit test from Visual Studio.
Then, when you run your vstest.console.exe command, you MUST use the parameter /TestAdapterPath.
Your command line should look like something (the path toward the xunit adapter is here relative so, you could put it in absolute or adapt depending on the active directory):
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:".\packages\xunit.runner.visualstudio.0.99.9-build1021\build\_common\"
edit: Because the adapter dlls are copied to the output folder, we could simplify the command line giving the path "." to the /TestAdapterPath option:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:"."
For information, it works also with NUnit, nuget package NUnitTestAdapter and the command:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" c:\path\to\your\assembly.to.test.dll /TestAdapterPath:"."
OK so problem solved, but after some frustrating troubleshooting that I will cover in case its useful for someone. The problem was that xunit.execution.dll was not available in the same folder as the dlls containing tests. This is required for xunit discovery. I only got here by:
Setting HKCU\Software\Outercurve Foundation\xUnit.net\Visual Studio Test Plugin\MessageDisplay = Diagnostic (this should be possible via the runsettings file but is not being picked up, and not possible via the VS tools options xunit page because its failing to open)
vstest now spits out 'Skipping xunitTests.dll (no reference to xUnit.net)'
This message actually means that xunit.dll and xunit.execution.dll weren't found in the folder
Problem solved by making sure that dll gets copied into that folder on the build boxes.
I'm trying to install a custom test adapter via NuGet, but it seems like VS isn't recognizing it. I've looked through the code in Microsoft.VisualStudio.TestWindow.VsAdapters.UnitTestExtensionDiscoverer, so I've realized the dll has to end with *.TestAdapter.dll. Using that name makes vstest.console work for me when I specify /TestAdapterPath, so I'm not sure why the VS2013 test window isn't showing my tests.
The adapter does work when installed by copying the relevant files to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions.
Are there any other path or filename conventions I need to follow for VS2013 to load my test adapter? Without any logging or error messages I'm really not sure how to gather more information to debug this.
The issue seems to have been that I was trying to debug by overwriting my dlls in the packages directory. This doesn't work because VS copies your package directory to something like:
%TEMP%\VisualStudioTestExplorerExtensions\My.TestAdapter.1.0.0.23
essentially caching it with the key being the version number. If you copy the file into the project packages directory VS won't copy it because the folder number didn't change. So, to update your extension you have to keep publishing NuGet packages.
At least that's how I understand it.
Edit: I've also noticed that when you upgrade your test adapter through NuGet, it won't start using the new version until you restart VS, or kill vstest.*
I am working on a windows as well as web projects. We currently use Visual Studio to build our solution using visual studio 2008.
I would like to move to a more powerful build system such as Nant or MsBuild for atomate.
What are the ways & how i do this?
Currntly we use Visual source safe & mercurial(hg) as source control
How does this all integrate with Source Control?
Help me all the ways..
Thanks!
Last time I checked, NAnt didn't support VS2008 project files properly.
I personally like using NAnt as the general build controller, but delegating to MSBuild for the core "build the code into assemblies" part. This has worked well for me in Protocol Buffers, for example.
I don't know about using either VSS or Hg from NAnt, but I'd be very surprised if there weren't adapters available. Where do you need to integrate source control with the build, is it for version numbers, continuous integration, or something else? You may find that whatever continuous integration server you're using can handle the source control aspect itself, and that your build file doesn't need to know about it.
This really depends on what you want to automate and how. Visual Studio Solution files can be called directly from MSBuild, so to just build the solution without Visual Studio, nothing has to be done.
NAnt can call msbuild to build Solution files for you, so you can wrap you solution build in a NAnt script and do other useful things around it. This is how I usually do things. That way your build script and your solution files stay in sync.
NAnt has had VSS tasks since the dawn of time, so checking out the code is trivial. If they don't have a Mercurial task, there is always the exec task which will allow you to run any commandline program (I assume there is one for Mercurial).
Normally I have a build server with a working copy of the application/solution. Then, each night, the server calls a NAnt script that updates the working copy to the latest revision, and builds the solution using the msbuild task. Then you can do all kinds of nifty things like creating zips or tars, or even installers.