I've been fiddling with the TFS2015 task based build system for a few days now. The problem I keep on running into is the following:
I am trying to use nuget packages for my external references in my projects. These exernal references are actually not 3rd party libraries but simply other (shared) libraries of our company. I'm able to restore the packages in a task, but I can't figure out how i can make the "Visual studio Build" understand where to find the restored packages. It uses the hintpath in the project file to determine the location of the external libraries to include. However, these paths (which are used locally for development) don't match the paths used on the build server. I can add a referencepath to the msbuild parameters, but this path isn't searched recursively, and the nuget package restore restores packages including the entire folder structure of the package.
My question is. Is there a proper way to make the "Visual Studio build" step understand the location of my packages without changing the hintpath in the project file. If not, what is the normal way to go here. Should I move away from nuget altogether because our references are not actually 3rd party libraries, and if so, what is the alternative way of resolving the references (without adding the binaries to source control)
My question seems to be related to Storing nuget packages in alternate location on build server, however he seems to have fixed it using a copy to the location that is specified in the hintpath of the references, which is not an option for me. It seems to me there should be an easy way I'm not seeing to be able to point msbuild to the correct location for the libraries.
After the task restoring packages, you can add task "Copy Files" to copy the packages to the location "..\packages\lib\lib.dll"
Related
asp.net core 2.2 publish generating lots off DLL in output directory(bin\Release\netcoreapp2.2\publish).
How I can move it to some other folder (bin\Release\netcoreapp2.2\publish\lib) & reference it?
Your question doesn't really make sense, but I imagine you're looking for a way to include a library from one solution in another. This is not the way to do that.
Instead, package your project as a NuGet. Then, you can reference the NuGet package in your other solution's projects. Some people are confused and think creating NuGet packages means having to make them public on the main NuGet repository. While you can of course do that, it's not required. You have a private repo, either through a third-party or deploy your own, or you can simply use a filesystem path or network location as a "repo".
In any case, creating a NuGet package is simple. You simply edit your project properties, go to the "Package" tab, and enable NuGet package creation. Fill in the relevant details about your package on that screen, and you're off to the races. Whenever you build or publish your project, you'll get a NuGet package created in the same directory. Then, just push that to your NuGet repo, or if it's a filesystem path or network location, copy it there.
I have install some asp.net core mvc dlls (Microsoft.AspNetCore.Mvc.Abstraction.dll). I want to decompile it and see the source code.
The dll is added to my project>Dependencies>Nuget.
However, I am not sure where exactly the dll in in my system.
Is there a quick way to just launch the added dll in ILSypy and see the codes or at least the object inheritance tree?
Thanks.
ASP.NET Core is open source, so as Hans wrote as a comment to your question, you can look directly at the source, you don't need to decompile.
But for future reference, NuGet dlls are extracted to one of two places. Older projects still using packages.config, the dlls are typically extracted to a folder named packages as a sub-folder of where the .sln file is.
Packages using PackageReference, the packages are extracted to your account's global packages folder, which by default is %userprofile%\.nuget\packages on Windows and ~/.nuget/packages on Linux and Mac. You can also look at your project's obj\project.assets.json file to find the paths to everything referenced.
All paths can be modified with nuget.config settings (or even msbuild properties for projects using PackageReference). But if this is the case, either you, or your team mate would probably know, so the default locations for the folders I listed above should be correct.
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 solution file in TFS, located at $/Library/Library.sln, containing the binary files (.dlls) of other built solutions in TFS. Within this Library solution, there is a .dll taken from $/MySQL/bin/Debug/MySQL.dll which has been generated by building my MySQL solution (located at $/MySQL/MySQL.sln).
Normally after making a change to my MySQL solution I build the solution, check it in to TFS and then copy the resulting .dll into my Library solution at $\Library\MySQL\MySQL.dll. However I’d like this process to be automatic i.e. after checking in a change to the MySQL solution, a build is triggered, and the .dll file generated from this build is automatically placed into the Library solution and then checked into TFS. How would be the best way to achieve this? I imagine gated check-ins are something to do with it but I can’t seem to get it to work.
As Daniel said in the comment, NuGet is the way to go for this. Instead of checking in the binaries to TFS, have your MySQL build publish the binaries to a nuget feed. Then have your Library solution "subscribe" to that NuGet feed.
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.