I installed both the elmah.mvc and elmah.sqlservercompact (package link) nuget packages. This gets elmah to log to Sql Server Compact.
Problem is it copies a large number of files from the _bin_deployableAssemblies folder, on every build.
How do I change this to deploy/copy only if file has changed, like I can do for other resources?
Seems when I install the SqlServerCe package manually, it doesn't add all those binaries to the build file.
Related
I have a .Net Standard project in a solution and I want msbuild to build it on our build server. If I do not run "nuget restore" first, I get the error "project.assets.json' not found. Run a NuGet package restore". I already have all of the necessary NuGet packages in the "packages" folder at the solution level. I would like to indicate somehow that msbuild should just use the files in the local "packages" folder instead of trying to re-download the files. How can I do this? Thank you.
.NET Standard projects do not use the packages folder in the solution. This is the "old" way of referencing NuGet packages through packages.config. The new way - PackageReference items in the project - uses a shared global packages folder in the user's home directory. The project.assets.json needs to be regenerated on the build machine with the resolved paths to this shared cache even if no packages need to be downloaded. In fact, a NuGet restore might not even need to hit the network if all packages are already on the machine.
The best solution I have come up with still involves a NuGet restore, but I added the local packages folder as one of the NuGet repositories in nuget.config and now I don't have to reach out to any remote repositories. This is not quite what I wanted, but it is allowing me to progress.
<packageSources>
<add key="local" value=".\packages" />
</packageSources>
The entry point assembly for our application is signed with a strong-name key, so .NET requires all referenced assemblies to be signed as well. For those packages that publish unsigned assemblies our workaround was to sign them manually using ildasm/ilasm with the process explained here, and checked in the strong-named assembly to git repository.
On the build machine we did git pull to get signed DLLs and then .nuget\NuGet.exe restore App.sln to restore the rest of packages. NuGet restore did not overwrite the signed/checked-in assembly files under packages folder, so we could build the solution fine.
Only recently I noticed that this is not working anymore and only for one of the signed DLLs nuget restore overwrites it with the original unsigned assembly that comes with the package. I cannot figure why this is working differently now and why it's happening for only one of the packages.
How does NuGet restore decide when to overwrite an existing DLL for a package and when to skip it?
Is there any better way to address this strong naming requirement when using unsigned packages?
NuGet.exe version is 3.4.3.
Thanks!
Looking at the latest NuGet source it looks to me as though there is an initial check for any missing .nupkg files in the packages directory, I am assuming that you are not using a project.json file, and then it tries to restore only those NuGet packages where it cannot find an .nupkg file. However this is just me reading the code and ideally I would need to debug it to see what if that is how it really works.
To workaround this you could take a look at using the StrongNamer NuGet package which will strongly name all assemblies at build time so the restore will no longer be a problem.
I have a Team City Nuget build setup which works fine. However, I have tried to update some nuget packages, one of them being: Microsoft.AspNet.Mvc. This was updated from version 5.2.2 to 5.2.3.
This broke the build. Examining the logs I noticed that the nuget package restore seems like it didn't even try to install Mvc. However, the packages folder that was generated by Team City has a Microsoft.AspNet.Mvc.5.2.3 folder but there is no dll file in the lib folder.
I'm at a loss here I don't see why updating to different package version breaks nuget restore.
Any insights on this behavior? Thanks in advance.
Delete the "Microsoft.AspNet.Mvc.5.2.3" package folder completely. The NuGet restore action should recreate this folder and download the assembly or assemblies correctly which are supposed to be in the "lib".
I've got the exact same issue on my build server and that solved the issue.
Check all of your projects in the solution and make sure they're targeting the same version of the .NET Framework. I've seen this flip out a build server before.
Also check in your solution packages directory and make sure that all projects that contain references that are packages are listed in the repositories.config file, so that they all get restored properly on the build server.
Thought I would try and get the most out of my visualstudio.com trial membership. I created a solution with a few projects, pushed it to the Microsoft git source control provider, configured a build definition and tried to build it on the project server. However it keeps failing telling me:
The type or namespace name 'Moq' could not be found (are you
missing a using directive or an assembly reference?)
I know this means that the build server can't find the Moq.dll library. I had installed it using NuGet, but configured my .gitignore to keep the packages folder out of source control. I also enabled NuGet package restore for the solution and pushed nuget.exe, nuget.targets, and nuget.config (all 3 of the files in the .nuget folder) along with all of the other project files.
Now I am sure I could get the build to work if I pushed the packages folder too, but I want to keep the nuget packages folder out of source control. So I am wondering, is this possible? The visualstudio.com docs say that the build servers have visual studio 2013 installed, and because of this I assume that nuget package restore would work to download the missing dll's so that they can be resolved by MSBuild. Is this right? Or to use automated CI builds at visualstudio.com, do you need to have your packages under source control?
According to the log file, nuget package restore downloaded the package. What gives?
Project "C:\a\src\MySln.sln" (1) is building
"C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj"
(3) on node 1 (default targets). RestorePackages:
"C:\a\src.nuget\NuGet.exe" install
"C:\a\src\Tests\MySln.ProjA.UnitTests\packages.config" -source ""
-NonInteractive -RequireConsent -solutionDir "C:\a\src\ " Restoring NuGet packages... To prevent NuGet from downloading packages during
build, open the Visual Studio Options dialog, click on the Package
Manager node and uncheck 'Allow NuGet to download missing packages'.
All packages listed in packages.config are already installed.
PrepareForBuild: Creating directory "obj\Debug\".
ResolveAssemblyReferences: Primary reference "Moq". C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1635,5):
warning MSB3245: Could not resolve this reference. Could not locate
the assembly "Moq". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
[C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj]
This line is also in the build log file, below the above:
Considered "..\packages\Moq.4.1.1311.0615\lib\net40\Moq.dll", but it didn't exist.
I had this same error but it was occurring on our build server. I had added Moq via NuGet, checked in the project and everything was fine. I then moved the project into a new folder in TFS and the build server just couldn't seem to find Moq. It was building great locally. I ended up fixing the problem by making sure all of my changes were checked into source control and then deleting my local source code directory. I got latest and my test project realized it needed a new copy of Moq. I blame TFS/ source safe or what ever the Visual Studio integration module is for not adding it to source control at some point in time.
Figured this one out on my own. Turns out I had added the nuget packages before moving the test project into a Tests subfolder. The solution still built on my LM, probably because the dependencies were already copied to bin/Debug. After reinstalling the nuget packages, the solution built on vs.com.
Background
I have an MVC3 project to which I added the Twitter.Bootstrap.Less Nuget package.
To my knowledge, all this did was copy the appropriate JavaScript / LESS files into their appropriate directories.
However, when I now run this through my build/deploy process onto my dev server, MSBuild doesn't copy the /Content/less folder to my production server as part of deployment package.
My build server doesn't have an internet connection, so unfortunately using NuGet without committing packages to source control isn't an option.
Question
How do I get MSBuild to deploy these files? Or do I need to copy the files, uninstall the nuget package, and manually copy them back in?
You could setup your own internal NuGet package source. That would be internal to your network and mean the build server could pickup the NuGet packages without an internet connection.
E.g. On the server, copy the packages you need to a folder and setup a package feed to that folder for the build server to use.
See:
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds