none
Debug or Release what files should I copy to target location in nuget packaging for uwp apps? RRS feed

  • Question

  • Hi, I am creating a nuget package for consumption for all my uwp apps. I have done, but I am not sure, what files(Debug or Release) should I copy to target location in nuget packaging for uwp apps? Since, in the documention example ms has provided, they use only debug files. why do they copy only the dubug files? why not release. What I learned/thougt from my past is, I should deliver only the release contents/components to the clients. What should I do?

    * Copy Debug files
    * Copy Release files
    * Copy Both (Debug & Release files)


    Source: https://docs.microsoft.com/en-us/nuget/guides/create-uwp-packages-cs




    • Edited by Bhadurudeen Saturday, June 27, 2020 3:49 PM
    Friday, June 26, 2020 6:21 PM

Answers

  • Debug/Release is a build configuration. When you're debugging your code you are building using the Debug configuration so you get extra debugging information and no optimizations so the code runs slower. However as soon as you want to release something you should be building against Release. This strips out some of the debugging and allows optimizations which speeds up the code. You should never use a Debug build in NuGet, there is no reason.

    If you are using the SDK project format then NuGet is built in and you don't need a nuspec file or to do anything. It works automatically, just build using Release. If you are using the original project format then you have to do it yourself. What most people do is set up a post-build event for the Release configuration that automatically builds the package, unless you have a build system.

    In general you shouldn't be putting paths into your nuspec file as it makes it hard to build it. The correct approach is to put your nuspec file into your output folder with the correct format and then run nuget to package it. This allows you to build it in any configuration. But if you must have paths then the Release build is correct, but you can then only run it in Release builds otherwise it'll fail. Also note that you should be including the binary and PDF files as well to allow for debugging. For class libraries you should also strongly consider including the SymbolLink NuGet package in your code so that people can step into your code by pulling the source from Git/Github. But that is a nice to have.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Bhadurudeen Tuesday, June 30, 2020 7:24 PM
    Monday, June 29, 2020 1:55 PM
    Moderator

All replies

  • Hi Bhadurudeen,

    Thank you for posting here.

    Since this thread is related to nuget, so I suggest that you can ask this question in stackoverflow.

    The Visual C# forum discusses and asks questions about the C# programming language, IDE, libraries, samples, and tools.

    Best Regards,

    Timon


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, June 29, 2020 5:59 AM
  • Debug/Release is a build configuration. When you're debugging your code you are building using the Debug configuration so you get extra debugging information and no optimizations so the code runs slower. However as soon as you want to release something you should be building against Release. This strips out some of the debugging and allows optimizations which speeds up the code. You should never use a Debug build in NuGet, there is no reason.

    If you are using the SDK project format then NuGet is built in and you don't need a nuspec file or to do anything. It works automatically, just build using Release. If you are using the original project format then you have to do it yourself. What most people do is set up a post-build event for the Release configuration that automatically builds the package, unless you have a build system.

    In general you shouldn't be putting paths into your nuspec file as it makes it hard to build it. The correct approach is to put your nuspec file into your output folder with the correct format and then run nuget to package it. This allows you to build it in any configuration. But if you must have paths then the Release build is correct, but you can then only run it in Release builds otherwise it'll fail. Also note that you should be including the binary and PDF files as well to allow for debugging. For class libraries you should also strongly consider including the SymbolLink NuGet package in your code so that people can step into your code by pulling the source from Git/Github. But that is a nice to have.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Bhadurudeen Tuesday, June 30, 2020 7:24 PM
    Monday, June 29, 2020 1:55 PM
    Moderator
  • You should never use a Debug build in NuGet, there is no reason.

    Great! Thank for your concrete answer.

    Secondly, You have said "If you are using the SDK project format..."

    I am creating "Windows Runtime component (universal windows) + added new class library (universal windows)" to create a nuget package to be consumed in my uwp projects. I think it is not a SDK project, am I correct? 

    Thirdly, you have said "In general you shouldn't be putting paths into your nuspec file as it makes it hard to build it. The correct approach is to put your nuspec file into your output folder with the correct format and then run nuget to package it."

    It seems interesting and useful. I post it in a separate question.


    Tuesday, June 30, 2020 5:09 AM
  • " I think it is not a SDK project, am I correct? "

    Easy way to tell. Single click the project name in Solution Explorer. If it opens the project file it is SDK. If it doesn't then right click the project and look for Edit Project File. If it is there then it is an SDK format. Otherwise it is the older format.


    Michael Taylor http://www.michaeltaylorp3.net

    Tuesday, June 30, 2020 12:50 PM
    Moderator
  • It neither opens the project file, nor there is a 'Edit Project File' command.

    However, I followed this microsoft documentation. below is my myprojectname.csproj file. It does not contain the sdk atrribute. So my project is a non-SDK format project. Am I right?

    Tuesday, June 30, 2020 3:53 PM
  • No it is not an SDK format. Not all project types currently support it so stick with the nuspec file approach for now.

    Michael Taylor http://www.michaeltaylorp3.net

    Tuesday, June 30, 2020 4:46 PM
    Moderator