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.
Related
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.
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"
I'm setting up a CI with TeamCity 8 (v8.1.4).
I finally managed to setup TFS integration - ie checkout from TFS.
I used the super easy Auto Detect Build Steps [thank you JetBrains for that] to determine the Build Steps necessary.
I used the Get missing NuGet packages step, which works as expected.
Then I have a Visual Studio Solution build step, that seems to build great, just until the point where it wants to build the Unit Test and Integration Test projects, which both use Microsoft Fakes.
Here I can see that TeamCity tries to search everywhere for the [AssemblyNameUnderTest].Fakes.dll - where [AssemblyNameUnderTest] is whatever dll that is tested.
I haven't included that dll to my project nor in TFS, since I thought that it would be regenerated each and every time I change something to the original AssemblyNameUnderTest (ClassLibrary) Project.
Should I include the [AssemblyNameUnderTest].Fakes.dlls to the project and TFS or am I right that they are regenerated ?
And if I'm right with the regeneration, then why TeamCity can't find it ?
Thanks in advance,
Michael
Ah, so I found the answer to one of my questions: http://hamidshahid.blogspot.be/2012/11/microsoft-fakes-framework.html
The files in the "Fakes" folder are only generated at the time of
adding the fakes assembly. They are added to the solution and should
be checked into source control.
The "FakesAssemblies" folder and all the files in it are generated
whenever the project is compiled. This is important because if you are
adding fakes for assembly for a changing component, the generation of
FakesAssemblies will ensure that all changes are reflected in the
generated assembly.
So I did that - ie it is the default behaviour.
Above that my .fakes files have the "Fakes" build action, but it still isn't working for TeamCity.
Also, TeamCity uses the MSBuild.EXE from "C:\Program Files (x86)\MSBuild\12.0\Bin" for the build.
Anyone a bright idea ?
To fix the build, I removed the Fakes stuff and implemented Moq mocks.
Seems to give you more control of what exactly happens.
I wrote up a quick WiX preprocessor extension to grab some product version information from a file we keep in our root folder.
I'd like to keep this extension in the same solution as our WiX setup project, because it's easier to maintain. But the problem is that when testing, we use a Debug configuration, and when releasing a build, we switch to Release. This means that I have two extensions to deal with.
How would I tell WiX to grab one depending on the current configuration?
I've been looking at the reference paths in the WiX project's properties, and added "..\MyWiXExtensions\bin\$(Configuration)\" as a folder, hoping that it would pick up the MSBuild property, but that doesn't seem to work.
I've also looked at the build events. I could copy the output dll to my setup project's folder, but wouldn't that break references if I clean my solution?
I'm using WiX 3.7 and Visual Studio 2012.
I ended up using a post-build event on my extension that would copy the output to my wixproj's folder.
I just have to build my wixproj separately from the rest of the solution to prevent file locking issues when overwriting the dll. If file locking does come up, I just have to close VS and reopen the solution.
As a side note, referencing the project itself instead of the dll could be a nice feature to have in Votive.
We are using a Cab Builder project in VS2008 to generate our CF cab files. This works well until we make changes that affect the dependencies. The Cab Builder project decides we need all sorts of additional libraries (mscorlib, etc.) that we don't need to actually deploy in our cab. We select the libraries and explicitly exclude them and commit the changes to svn -- when the build server gets the latest of the project and builds it the rogue libraries are back. We have to actually open the cab project on the build server and (again) manually exclude the libraries we don't want to include.
Is this normal behavior for the cab builder?
Is there a work around?
Will we have less pain if we give up and generate our .inf files with a different method and run the exe on the build server to generate the cabs instead of using the project?
Thank you
Ah, the CAB deployment project. I swear that thing was an afterthought and tasked out to a couple interns to develop. It's absolute garbage for anything but the most simplistic packaging scenarios.
What we do is we hand roll the INF and then call cabwiz manually. I've done this with the aid of MSBUILD to make automation pretty simple.