I think I'm missing something here. I installed Tesdriven and then Gallio (third link from top - Gallio 3.5 x64 installer)
Then I installed the mbunit dlls from Nuget because I didn't want to include a dll from my hard drive as it makes it difficult for the project to be ported to other machines..
However, when I try to run a sample test, testrunner insists that I reference the dlls from my hard disk.. the actual error message is this:
It looks like you're trying to execute a Gallio/MbUnit unit test.
For Gallio v3.0.6 build 787 / Gallio v3.1 build 313 or above (recommended):
Please ensure that the directory containing your 'MbUnit.dll' reference also contains Gallio's
test runner files ('MbUnit.dll.tdnet', 'TDNet\Gallio.TDNetRunner.dll', 'Gallio.dll' etc.)
For earlier versions:
You need to install Gallio (after TestDriven.Net) using its MSI installer.
You can find Gallio downloads and support here:
http://www.gallio.org/
So, is there a way to get testrunner to run the tests with just nuget packages, please?
Currently nuget gallery has only 3.3.1 version of mbunit package, and you installed Gallio v3.4. It's very annoying limitation of gallio and mbunit. In order to use nuget package you have to downgrade Gallio on your machine to v3.3.1. Better solution it's mail to gallio/mbunit team and ask to upload nuget package with latest release or make it by yourself.
Related
I have Nuget Server on TeamCity and when i try download package from server to dnx project list of the packages is empty, but when i try manualy add to project (by project.json) then it works.
How i should configure my TeamCity Nuget server or something other?
It appears that this is an issue with TeamCity's NuGet server as NuGet's public servers behave just fine. If I were to guess, there is some problem with passing in arguments for .NET Core assemblies / framework projects.
You want to have the TeamCity .NET Core plugin installed on TeamCity and use the "dotnet restore" command -- with the TeamCity URL for your NuGet package - and it should work as expected after that. For solutions mixed with csproj and xproj files, it has been my experience that you need a NuGet Installer and dotnet restore build step to get the job done. For NuGet, you want to have 3.5.0 (only available in beta at the time of this writing) or later to understand projects that contain a project.json -- and to not error out.
How can I install nuget packages for my PowerShell Projects in Visual Studio 2015? I have tried to do it with both the PowerShell Module Project and PowerShell Script Project. I have installed PowerShell Tools for Visual Studio 2015.
When I open these projects, the Default project in the Package Manager Console is empty. Here is a screenshot of what I mean.
When I try to install a nuget package, e.g. Pester, I get the following error.
I know this thread might be outdated and is rather old but my older article with some possible solutions might help here. I tested current state and still, no support inside VS 2015 for PowerShell project and NuGet packages together.
the current state is :
go with https://chocolatey.org/ and install it on your dev box (and CI) => you install pester globally with : choco install pester and update it if needed.
use old packages.config and update by hand version number and run nuget restore (nuget update will no longer work for this type of solution).
version whole pester into repo and call it directly. you can use nuget install pester for this (if you have nuget in path somewhere)
The link : http://rostacik.net/2015/12/16/how-to-use-nuget-packages-even-with-powershell-projects-with-visual-studio-2015/
Due to a bug in the Roslyn compiler, I cannot build my project using v1.0 of the compiler (there is no workaround to make it work on 1.0). However, Microsoft has corrected the issue in a more recent version of the compiler.
When using Visual Studio, you can use a specific version of the compiler by adding the NuGet package available from https://www.nuget.org/packages/Microsoft.Net.Compilers/ to your project. This causes Visual Studio to use the specified version of the compiler when building the project.
However, when attempting to run a build on TeamCity, it does not seem to know to use the new version of the compiler. It only allows one to choose which version of Visual Studio to use. Is there any way to specify to TeamCity which version of the compiler to use manually?
Note: I am using TeamCity Professional 9.1.3 (build 37176) and in the build step I have chosen Visual Studio 2015.
When built locally, the build is done using:
D:\BitBucket\LocalPackages\Microsoft.Net.Compilers.1.1.0-beta1-20150928-02\build\..\tools\csc.exe /noconfig /nowarn:1701,1702,2008 ....
But when built on TeamCity, the log shows:
[Csc] C:\Program Files (x86)\MSBuild\14.0\bin\csc.exe /noconfig /nowarn:1701,1702 .....
I have also confirmed that the package is installed as part of the TeamCity build (prior to the csc command):
[Exec] Installing 'Microsoft.Net.Compilers 1.1.0-beta1-20150928-02'.
Is this just a symptom of how NuGet can behave differently in the Visual Studio UI vs. Command line? And if so, is there a workaround?
Update:
I never did figure it out. Running the build in Visual Studio on the build server worked perfectly, but running the build using the exact same files through TeamCity did not work.
However, Microsoft released VS2015 Update 1, which resolves my original issue, though not this specific problem.
The Microsoft.Net.Compilers package is using the standard Nuget tooling. Specifically, there is a build folder in the package, which contains a props file. This props file gets injected into the csproj file, and is responsible for changing the csc executable to the one in the package.
If you are using msbuild 14, then the .props file is changing the CscToolPath, and the CscToolExe to point to the csc.exe in the package. So you just have to make sure that TeamCity is using msbuild 14.
Which version of TeamCity are you using? The documentation of 9.1 says that it supports msbuild 14 (msbuild 2015). If you are on older version, you could still use msbuild 14 from the command line runner.
Using team city as our CI and I've started getting this error message. We've obviously updated System.Net.Http recently which now needs a new version of NuGet. How do I get team city to find the new NuGet version. I've tried installing VS2015 and updating NuGet package manager through there. I've tried pointing directly to the command line nuget.exe (Don't know if that's been updated to v3?)
[restore] The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60717.93'.
[restore] Process exited with code 1
Do I just have to just wait till MS pushing the new nuget package to nuget?
Thanks
On your teamcity client you can configure the nuget versions available to your build agents.
Go to Administration -> Integrations -> NuGet
From this screen you can click Fetch NuGet and retrieve the latest version. Then you should be able to specify that version on your build step.
Download NuGet 3.1 from this url:
http://dist.nuget.org/win-x86-commandline/v3.1.0-beta/nuget.exe
Then put that on your build server, put the directory in your path, and run your NuGet build steps as "Command Line" commands in TeamCity, using NuGet.exe.
I think you need TeamCity 9.1, as that version contains the VS2015 build tools: https://confluence.jetbrains.com/display/TCD9/What%27s+New+in+TeamCity+9.1
NuGet 3.0 was released with VS2015: http://docs.nuget.org/release-notes/nuget-3.0.0
In earlier versions of Visual Studio you could add a System reference to System.Net.Http, but Microsoft has now moved that into a NuGet package.
I recently installed Visual Studio on a new computer and as a result I now have Nuget 1.5.2. This version doesn't seem to work with my old solution. When I add a new project and try adding references via Nuget, it says they are already installed and does nothing, even though that reference doesn't exist in the new project.
Does anyone know why this might be happening or alternatively where I can download the old Nuget (1.4.2)?
Thanks!
The NuGet Command Line is available as a NuGet package.
Just like with any other NuGet package, you can get a specific version by using the -Version switch in the Package Manager Console.
To get v1.4.2 of the NuGet command line tool, you should execute the following PowerShell script from the Package Manager Console:
Install-Package Nuget.CommandLine -Version 1.4.20615.182