See attached image - I'm trying to build 3 Class Library Projects in VSTS all of which include Newtonsoft.Json as a NuGet package - but I'm getting a bunch of errors relating to Newtonsoft tests etc that I am at a loss to resolve.
I've updated all 3 class projects to 4.6.1, I've upgraded all NuGet packages and performed an Update-Package -reinstall.
I'm pretty new to VSTS builds, can't find anything relevant on Google around the Newtonsoft tests and I don't know why VSTS is finding references to Newtonsoft.Json.Net20.sln as it's not part of my git repository or projects.
If it's trying to build it, it's definitely in your repo.
If you don't want it to build, change the pattern in the Visual Studio Build step to only build the relevant solutions. The default pattern is **\*.sln, which will find and attempt to build all the solutions in your repository.
Related
I have a C# solution which contains 3 projects; Application.Server, Application.Client, and Application.Common. Both server and client have a project reference to common.
I want to pack server and client up so that they can be used by other teams in my organisation. I have some automated build pipeline set up that do so, and they publish the nuget packages for server and client. They do not package or publish common. When I inspect the nuget packages, I can see that they reference the common package.
Is there a way that I can get them to build that project into them self? Ideally I don't want to publish the common package as it's pretty specific to my application, and it doesn't really make sense that it's something that's independently consumable by other departments. I also don't want to have to worry about wrangling extra nuget packages if I can help it (as in reality, Common is actually several projects).
If your projects are "old style"/non-SDK/traditional csproj, AND if any project uses a NuGet package, if all those NuGet references are defined using packages.config, then use you can use nuget.exe pack -IncludeReferencedProjects. However, if any of your projects use PackageReference to define their package references (new, SDK-style projects can only use PackageReference), then nuget.exe pack will not correctly create NuGet dependencies for those packages. For SDK style multi-targeting projects, nuget pack will probably completely fail.
The only supported way to pack projects that use PackageReference, or any SDK style project, is to use NuGet's MSBuild pack target (either dotnet pack or msbuild -t:pack). However, this does not have an equivalent to nuget.exe's IncludeReferencedProjects.
If your projects are SDK style, it really shouldn't be any more difficult to create and publish one package or many packages. Simply run dotnet pack on your solution, and every packable project gets packed (remember to mark any class library project you don't want to become a package as not packable). Then use your favourite scripting language to find and publish all nupkg files. For example (Get-ChildItem -Recurse -Filter *.nupkg $SLN_DIR | ForEach-Object { & dotnet nuget push $_ }, or copy/move all nupkgs to a single place (or use the appropriate setting to make NuGet create the packages there in the first place) and use dotnet nuget push *.nupkg.
The NuGet team recommends one package per assembly, and the tooling automatically creates NuGet dependencies for project references, so it all "just works" out of the box. To create a package with all the assemblies included, instead of NuGet dependencies, requires you to do a bunch of work.
I've got a cross platform (iOS and Android) Xamarin solution using .NET Standard 2.0. The solution is being built by Visual Studio 2017 (I've tried both the current and preview versions). The Forms and Android projects build fine. However, the iOS fails to build, with the following error:
1>CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\Users\newuser.nuget\packages\system.reflection.emit\4.3.0\ref\netstandard1.1\System.Reflection.Emit.dll' and 'C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\Xamarin.iOS\v1.0\Facades\System.Reflection.Emit.dll'. Remove one of the duplicate references.
I've tried many work arounds as described here:
oren.codes
www.hanselman.com
github.com/NuGet
Unfortunately none of these suggestions work. I have also tried to add the System.Reflection.Emit nuget package directly to the Forms and/or to the iOS projects directly. This doesn't work either. Note that originally, the The System.Reflection.Emit package wasn't referenced directly by anything in the solution. It is being pulled in by the following nuget packages which are being explicitly referenced:
Acr.DeviceInfo (5.0.5)
akavache (6.0.0-alpha0038)
AutoMapper (6.2.2)
Microsoft.Identity.Client (1.1.1-preview0040)
Newtonsoft.Json (10.0.3)
Finally, I have tried the update-package -reinstall command in the package console to reinstall all packages for the iOS project. This doesn't work either.
-- update
Just to make this clear, neither the Xamarin Forms or the Xamarin iOS project directly reference System.Reflection.Emit. That package is being pulled in as a dependency of other nuget packages, just from packages that are installed into the Xamarin Forms project. I have confirmed all of the dependencies that are referenced by Nuget, are using the same version. See these screenshots:
It seems to me that the problem (as the error says) is that there is an old version of System.Reflection.Emit that was installed by Visual Studio. However, I can't find a way of ignoring it and using the version of System.Reflection.Emit instead. As I've said above, I have tried to use a project.json file in the Xamarin.iOS project, and manually ignoring, but this doesn't work.
Does anyone else have any ideas?
As an aside, I notice that this bug is still open for Xamarin.
Xamarin Bugs
Managed to get this resolved thanks to an answer by #DirkWilhem on Xamarin Forums site.
Basically, add this to your Xamarin iOS project's .csproj file, with the other PackageReference nodes:
<PackageReference Include="System.Reflection.Emit">
<Version>4.3.0</Version>
<ExcludeAssets>all</ExcludeAssets>
</PackageReference>
Of course you need to make sure the nuget package has been added to the iOS package first.
Xamarin Forums discussion
After spending hours trying to resolve this myself I may have found a solution. Although it does feel wrong, it has got me past the issue.
Moving/Deleting the Xamarin.iOS version of System.Reflection.Emit.dll has solved the build problem for me and enabled me to deploy and run my app on a device. I don’t know what side effects it might have so will need more testing but I thought I’d share what’s worked for me so you can test it as well.
I was running on macOS Visual Studio 2017 but switched over to Windows to try and fix and first fixed on there then tried same approach on macOS and it worked as well.
On windows, go into the following directory and move the System.Reflection.Emit.dll somewhere else (you could just straight up delete it but I wanted to keep a copy I case this has some undesired effects down the track):
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\Xamarin.iOS\v1.0\Facades
On mac the following directory has it:
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades
Like I say, it feels wrong but for now it’s got me past an issue that’s had me blocked for a couple of days so willing to just move on and hope there’s no side effects. I’d be interested to know your experience with it and if you come across anything else for the future too.
I’ll post this same comment on the Xamarin forums post (https://forums.xamarin.com/discussion/120814/xamarin-ios-project-cs1703-multiple-assemblies-with-equivalent-identity-have-been-imported) as well for future reference.
I had the same issue around a custom Nuget packages that we created and consumed in a separate project. We got around this issue by removing the automatic Nuget building checkbox in the "options" for the project. This does add the extra step of "Create Nuget Package" but one we pushed it to our Nuget repo and consumed it in our project, the errors vanished.
The problem showed up when we updated the sub-projects from PCLs to .netstandards (2.0).
I am trying to create Team City build template which requires minimum customisation, and I want it to play nicely with legacy projects and projects developed with .NET Core/Standard and .NET CLI.
I am stuck with NuGet as there were some considerable changes in how things work.
Earlier we had to create nuspec file to pack project as a NuGet package. At least in that file we could define various package-related properties.
New csproj file format allows us to define all package properties inside itself. That's fine, but how then do we know which projects should be packaged and which should not?
So far our TeamCity's build step Pack NuGet just contained **.nuspec for Specification files: field. The very fact of nuspec file presence served like a flag pack & publish this project.
However, for dotnet pack we need to specify the project. There is no simple way to distinguish 'main' projects from 'auxiliary' ones on which mains depend. (Let us ignore that project-to-project references are currently not supported.)
We either could pack all projects specifying **.*proj (yet in that case we are to know which packages to publish) or we might specify projects explicitly in a build configuration, but I don't like this approach because you must edit build configuration each time new project is added to the solution.
I also considered the option Generate package on build and omit dot net pack step as package is created on build. The only thing left is publishing the packages with dotnet nuget push specifying **/%BuildConfiguration%/*.nupkg.
Unfortunately when starting build against solution without projects with enabled Generate package on build makes TC fail complaining that
Target files not found for pattern "**/Release/*.nupkg"
Hence, I either need another recipe for achieving the required result or an advice how to make TC consider empty result just as a NOP and mark build as successful.
Yet another option is to use nuspec even for new csproj...
Since TeamCity 2017.2 will be available option to associate build configuration with multiple templates. So you will be able to create different templates to create packages for old projects and new .NET CLI projects.
To specify paths for target .NET projects, which should be packaged, you could use build configuration parameters.
To set such parameters during the build you could send in the preceding build step service message. The value of this parameter could be set to the list of target project files which could be selected via script like that: https://stackoverflow.com/a/8153857/305875
About: I have a ASP.NET website (not Web project) with 3 class library projects in the solution. Earlier I was using SVN but now Git is used source management. I have installed the git locally on a computer (used as server) and using it for merging the source code from other developers. Also, I am using Visual studio 2015 community edition which provides the tools to work with git.
Problem: After cloning the project from the master repository, I build the project to run it. Building the project shows a dialog box saying "Package Restore is in progress". This process creates a folder named "Packages" and that folder includes every package listed in the packages.config file. But after restoration completes, the project throws the following exception:
This exception shows for each package (Autofac here).
The type or namespace name 'Autofac' could not be found (are you missing a using directive or an assembly reference?)
Work around To Solve this problem, I need to uninstall each package and installed it again and problem is solved. This thing I need to do again and again for each developer machine, which is frustrating and time consuming too.
Does anyone has faced the same problem working with Nuget, git and website in ASP.NET.
I faced a problem like this before. In my case, the reason was that I changed the project path (moved the project to another directory), and the path of the packages directory (that contains the NuGet packages) was stored in the csproj file for the old path, that is VS cannot restore NuGet packages. The solution for this was to edit the csproj manually and make it referring to the correct new packages path.
If this doesn't work for you, you can still use your workaround, but using the following PowerShell command (in NuGet Console) for simplicity:
Update-Package -reinstall -Project Your.Project.Name
Note: project name doesn't contain csproj extension, just the project name
It is good practice to not put third party packages into source control. It bloats your repository (even on a large web application, the size of the external packages will massively out weigh your code).
If NuGet package restore is slow, you could look at using a local cache (this can be as simple as a shared folder) or a better internet connection.
That said, you should only have this problem once per machine. While the packages are downloading you could be giving the new team member an overview of the design…
Make sure that all of your projects are using the same target framework, when this isn't done you can often get the
type or namespace [name] could not be found
warning.
To do this, right click each of the projects in the solution explorer > Properties > Application tab > Target Framework. They should all be the same or there will be incompatibilities between the references in your projects. Here's a question regarding this, hopefully this helps.
The main reason is there no Autofac reference in packages.config file.
When you see on the screen Restore packages message box this mean that nuget package manager is trying to install all the packages which are missing in the package folder.
Try to do this step:
In Visual Studio Solution Explorer pick the project and via context menu pick Unload project
After project was unloaded via context menu pick Edit your project
Go to section group and find you Autofac Reference section
If HintPath doesnt looks like ..\packages\Autofac.4.1.1\lib\net45\Autofac.dll (Actual for 4.1.1 version) remove the Autofac reference Item
Save csproj file and reload project
Install Autofac via NuGet Package manager
Commit and push changes to git repository
Had the same problem with VS 2019. In ASP.NET, packages are updated via the .refresh files that appear in your bin folders. If these aren't checked into Git, they wouldn't be copied down to your cloned repro.
I added the .refresh files for all of my package dlls, made sure the versions and paths in the .refresh files were correct, and now everything updates as expected.
All:
I need advise on how to use Nuget to make my project dependencies (libraries) available to other developers who will in turn have my project as dependency. See scenario below for details:
I have created a Visual Studio 2013 project (ProjA) in a solution (SolA) which has a dependency on a Library (LibA [which I do not commit into source control]). I have used Nuget to manage/fetch the dependencies of project ProjA (i.e. library LibA) via Nuget.Config in .nuget folder at solution SolA level and everything is working ok. Developers are able to checkout solution SolA and build/deploy with Nuget fetching LibA from a local server.
My issue is that I now need to have developers build their project (ProjB) in another solution (SolB) but which will import/use ProjA as a dependent project. Issue is that I cannot find a way to make Nuget fetch the dependencies of ProjA (i.e. LibA) when built as part of solution SolB. I tried putting the Nuget.Config File in the level of ProjA, but VS build seems to ignore it.
Any ideas????
You seem to be mixing two different but not-very-compatible approaches to code sharing here:
Code-level dependencies
Package-level dependencies
Code-level dependencies between different solutions are generally A Bad Thing, and you should avoid them. A solution should encapsulate and build all the source code it needs to, relying on 'library' DLLs (whether provided as raw DLLs or via NuGet).
I recommend that you re-work your solutions using the 'Package-level dependency' pattern, so that you have a separate 'library' solution which provides a NuGet package (or set of NuGet packages) which the other two solutions can consume:
Here is the current (awkward) dependency graph:
Solution A Solution B
Proj A -----------> Proj B
^--------------------'
Here is what I propose with the separate library solution:
+----> Solution L <----+
| |
Solution A Solution B
Solution A and Solution B thus consume the NuGet packages produced by Solution L (the library project). This is the dependency relationship which probably underlies your code anyhow, based on what you describe.