I am publishing my Bootstrapper.dll on a local nuget server during its build, and this is working fine. But to use it in my Bundle projects (wixproj), I can't find any direct method to reference this in PayLoad.
As a workaround I have created a dummy C# project, adding the nuget reference, Copy Local=True and then referencing this dummy C# project's TargetDir\Bootstrapper.dll in Bundle PayLoad.
Question: Is there any way to avoid using dummy C# project and using nuget referenced binaries in Bundle's PayLoad directly?
Thanks
You can install the NuGet package in your Wix Bootstrapper project. Create a install.ps1 to update Payloads in your Bundle.wxs. At the end of install.ps1 save the project.
$project.Save($project.FullName)
Don't forget to undo the changes made in install.ps1 in uninstall.ps1 to keep everything nice an clean.
The above described procedure will save you from creating C# dummy project.
Related
I have my own Nuget package and I want to "extract" it (get the dll inside it) without building the project.
Is it possible?
Can I do it to a specific folder?
If it is possible:
can I do it on "Nuget restore", "Nuget installation", project reference (when adding the project with the Nuget as a reference to other project)?
Is it possible to do a post-process such as writing the path of the extract dlls to a file?
Thanks.
I have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.
With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).
However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).
DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.
See the 'switch-to-packages' and 'switch-to-projects' command line switches.
Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.
https://github.com/RicoSuter/DNT
I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)
If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.
So nuget is not a good choice for your situation, you should use ProjectReference.
Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.
ProjectReference could cross two different solutions.
Add this on the main project:
<ItemGroup>
<!--add any nuget project'csproj file like this to debug its source code-->
<ProjectReference Include="..\xxx\xxx.csproj">
</ProjectReference>
</ItemGroup>
If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.
I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.
I have a program written in C# and there is a TwitchLib.dll that provides some stuff about Twitch.tv API I guess and I want to update the .dll since there were some changes in API. How can I get .dll from a nuget package (TwitchLib).
I've tried going to /.nuget/packages/twitchlib/3.0.1/ and there is no TwitchLib.dll while for example in /.nuget/packages/twitchlib.client/3.0.3/ there is. I need .dll that is for whole TwitchLib library, not only specific parts of library.
Just build the class library by clicking the right click on solution explorer and you will see the NameOfLibrary.dll file in packages folder of your project directory.
I'm trying to get my PCL library that uses Nuget packages to copy the dlls it requires to its output directory. For example, I use the Portable Licensing nuget, but it unfortunately does not copy its dlls to the output folder despite having tried multiple solutions/recommendations found on the web.
I've tried a few things based on this page: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Manually setting IncludeAssets to all for each nuget required, locking the dependencies, using the Target build arguments found in another post, etc. Nothing seems to work.
A couple things to note:
I cannot set anything in terms of the nuget refrence. Pic of what my properties window looks like: https://i.imgur.com/cvTQFM6.png
My project does not have a packages.json file. I created a blank project, added the nugets I needed, and copy-pasted the packages.json file from there to my main project, but it still didn't work. The blank project, when compiled, does have the dlls copied to its output directory.
This is a PCL project.
Can I use Nugets properly with PCL projects? Is there some setting I'm overlooking? Any help would be greatly appreciated!
There is one shared solution which uses packages (obtained via nuget, for example Elmah). This solution generates DLLs.
I have several solutions which want to use those dlls. I've added them via "Add reference".
This works when I have my nuget packages installed on every solution, but when i uninstall it from the descendant - it can't find it. I understand why (it does not copy folder with packages from sharedSolution, only generated DLLs), but I wonder what is best practice in such situation?
If you prefer to manage the DLLs shared across multiple solutions manually, the steps would be:
After loading the NuGet package to one of your solutions, navigate to the package location and copy all the required DLLs (with the supporting XML files, if any) to a separate folder (e.g. Vendors\SharedPackage.Version1).
Uninstall the NuGet package.
Now using "Add reference", navigate to the location where you copied the SharedPackage in step 1 (Vendors\SharedPackage.Version1 folder) and add the required reference to all projects and solutions you want.
Note: If you go down this path, you'll have to manage all the SharedPackage updates manually: Get the updated package via NuGet, copy the package contents to a separate folder (Vendors\SharedPackage.Version2), uninstall the package, remove references to the old package from all your projects in all solutions, add references to the new version of the SharedPackage.
Alternatively, if you want to have your NuGet packages managed by the Visual Studio, this thread is the best source of information I could find on this topic. Vermis has done a great research work!
P.S. Imho, the manual solution is easier to implement but harder to maintain. The decision is up to you.