Announcement

Collapse
No announcement yet.

Disable re-pulling of NuGet package files (such as deploy.bat) when updating?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Disable re-pulling of NuGet package files (such as deploy.bat) when updating?

    After I install the Bridge.net NuGet package into a project, it includes additional files such as deploy.bat (which seems to have a hard-coded reference to "MyMvcApplication") and clean.bat, along with licenses and the bridge.json file.

    I remove these from my project since I don't need them (aside from bridge.json) but when you release an update and I pull it in these files come back. I was wondering if it would be possible to disable that behaviour in most cases? I imagine that if you changed the license details then you might want to force those files to be included again, but if not then it would be nice if those project files could stay excluded after I've dismissed them once!

    The first time you install the package it makes sense, of course.

    On a related note, the way that I configure my solution is to have an MVC "main site" that references a Bridge.net project (or multiple, possibly). I change the bridge.json file(s) to push the generated JavaScript into that main site. This lets me reference any real C# libraries in that project (such as a CSS minifier or some WebAPI end points) on the front end while pulling JavaScript generated from C# in the other project(s). In this case it makes even less sense for the NuGet package updates to include a html in the Bridge.net projects! Is this the standard / recommended way of configuring a solution?

    #2
    Hi,

    The deploy.bat, clean.bat and License files are added by the NuGet installer. They are shipped with the NuGet Package, and if missing will be re-copied during an update. To keep these files from re-adding to the project we would have to remove from the NuGet Package. Removing might be possible for the .bat files, but they do serve a helpful purpose and do no harm.

    You can exclude those files from your source control system (E.g. adding to .gitignore) if you don't want to see them included in the repository.

    The License file must stay and you should keep the License file as well.

    The /Bridge/ folder should generally be thought of as under the control of the Bridge framework, similar to how the /Bin/ folder is under the control of the .NET compiler. Files may be added, removed or reconfigured in that folder by the Bridge Framework, such as writing and removing .js files from /Bridge/output/. Different Bridge NuGet Packages will also add files in the /Bridge/ folder, such as with the installation of some Plugins.

    Hope this helps.

    Comment


      #3
      I also found this an annoyance. I hate NuGet packages that clutter my project with junk (we have a Flickrnet.chm file in a web project here because of a bad NuGet package!), I just want to see my files.

      The .bat files seemed kinda useless to me; the project build already did what was needed. I can customise the output folder as required (and for the build server I'll have scripts anyway). It seems like these would be better as samples/docs somewhere, not dropped into every Bridge project.

      As for the licence, NuGet has a built-in way of displaying licences to users during package install. You can set requireLicenseAcceptance=true in the nuspec to force them to have to accept. Would this not be a better option? If every package we used dropped their own licence file in the project, solution explorer and the repo would become quite a mess ;(

      Comment


        #4
        Hi DanTup & @ProductiveRage,

        What are your thoughts on the /App_Readme/ folder? We could move the License document to the /App_Readme/, which is the recommended location anyways.

        I too have never been super thrilled with the clean.bat and deploy.bat files being included in the NuGet package, so these can likely be removed and replaced with a comment in bridge.json on where to acquire.

        If every package we used dropped their own licence file in the project, solution explorer and the repo would become quite a mess ;(
        Well, every 3rd party NuGet Package should be including their license in the project. The recommended location is the /App_Readme/ folder. My position is you should always have an copy of the license included with the project.

        I'm not a huge fan of using requireLicenseAcceptance=true with open-source licenses, especially Apache 2. The setting is certainly useful if requiring acceptance of a Commercial License.

        Comment


          #5
          I've created an Issue to track removal of clean.bat and deploy.bat from the NuGet Package.

          https://github.com/bridgedotnet/Bridge/issues/308

          Comment


            #6
            What are your thoughts on the /App_Readme/ folder? We could move the License document to the /App_Readme/, which is the recommended location anyways.
            This definitely sounds better, though I still think it's kinda overkill...

            Well, every 3rd party NuGet Package should be including their license in the project.
            I'm not really sure why they should. As far as I've seen, it's not common to pollute a project with a licence. We use large numbers of NuGet packages and I have only seen one or two dump things on our project folder (and I don't recall any being licences). This post from Phil Haack talks about pulling licences for NuGets out with a script - if it was common (or expected) for them to be in the project, I would've expected to see it mentioned in that post at least.

            Is there a reason why having it declared in the metadata or included in the package in a way that doesn't go into the project is not enough?

            Comment


              #7
              As far as I've seen, it's not common to pollute a project with a licence.
              They shouldn't be "polluting" the project. As a default location, it is my position that the license should be included in the /App_Readme/ folder for all packages. Out in the wild it may not be common for published packages to include a Licence document, but they absolutely should.

              - if it was common (or expected) for them to be in the project, I would've expected to see it mentioned in that post at least.
              Doesn't that post from Phil Haack demonstrate the point as to why you should have your licences packaged with your project? He didn't include the licenses (bad), then had to hack together a solution and waste time trying to acquire them (bad). Personally I wish NuGet forced developers to include a Licence document in their .nuspec config, and forced that document to be included in the project somewhere... for example in a standard location such as /App_Readme/Licenses/ or /App_Licenses/. This whole "App_" folder concept needs to be rethought too, but I digress.

              We chose to include all Bridge related documents in the /Bridge/ folder because we were already adding that root project folder upon installation. All Bridge related files are centralized in the /Bridge/ folder. We could easily spread them between the /Bridge/ folder and /App_Readme/, but that doesn't really seem to make the situation any cleaner.

              With the NuGet Package we're trying our best to simplify the installation process as best we can and to create the recommended structure for a Bridge project. The bridge.json file and /Bridge/ folder are not actually required for a Bridge project to compile. They just provide helpful organisation for keeping all the "Bridge" related elements and settings in one location, and simplify the installation steps for a developer new to Bridge.NET.

              One option I'm thinking about is creating a new NuGet Package call Bridge.Core. That would include only the Assembly References and adding the /App_Readme/ documents (readme, breaking_changes, license, etc). No root /Bridge/ folder, and no bridge.json would be added to the project. Calling Install-Package Bridge.Core would only added the minimum required for the project. For your scenario this is the package you would likely want to install.

              The Install-Package Bridge package would then have a dependency on the Bridge.Core package, but in addition would add a root /Bridge/ folder, bridge.json, and other misc files to assist with getting developers started quickly.

              I'll also mention again for anyone reading this thread in the future, it would be simple to set up a .gitignore rule to prevent any files from being pushed into your projects source repo.

              Hope this helps.

              Thanks for all your feedback.

              Comment


                #8
                Just to back up geoffrey.mcgill statements, the Apache 2.0 license we adopted for the project has in its 4.a. section the following text:

                "You must give any other recipients of the Work or Derivative Works a copy of this License"
                So that's why -- in efforts to follow the rules of the license -- we must provide it with the installed version of Bridge. Should it be on App_Readme/, Bridge/ or packages/Bridge<version>/lib (with the .dll files), we are supposed to provide a copy of the license with the NuGet package, source code, and also the .vsix package available from Visual Studio Gallery website.

                I really can't speak for the general NuGet packagers, but the correct thing, at least with our license, is to provide it in the package.
                Last edited by geoffrey.mcgill; 2015-07-16 @ 02:47 PM.

                Comment


                  #9
                  Nevertheless, whether it's written into the actual licence agreement or not, the document should be included with the package distribution and I feel it should always be "physically" available for review in the end developers product. Preferably in some dedicated or convention based location.

                  Comment


                    #10
                    I might be having a bit of a mental block here, but wouldn't the end user have to manually remove the files (license, readme) from the project if they were using .gitignore to exclude them? Otherwise, when checked out clean, the project would have warnings about files that are included in the project file but that are not present on disk?

                    Would it be possible for the proposed Bridge.core to include the files in the package but to not explicitly add them to the project? That way you would be following the letter of the apache license (by including a copy in the project) while not forcing its inclusion in the project (which I think is the project "pollution" that DanTup refers to) - in conjunction with a "must agree to license" configuration (requireLicenseAcceptance=true) surely this would cover all bases by ensuring the the user actually sees the license initially?

                    (I'm no expert in the preparation of NuGet packages, so it might not be possible to include files to include in the file system that are not explicitly referenced by the project file - so apologies if this idea is not technically possible!)

                    Comment


                      #11
                      Hello ProductiveRage!

                      You have a good point there, I must admit, I agree with you that we shouldn't be filling the project with stuff not pertaining it. But as Bridge creates its own "Bridge" directory, where bridge.json file must be in, would that hurt to have a license file over there? After all, Bridge-related stuff must be somewhere in the project (as bridge.json file), and so, Bridge's license file.

                      Maybe this would sound better than having it inside a App_Readme folder?

                      Technically speaking though, another option that might meet your suggestion would be to add the license file inside either of NuGet's 'tools/' or 'build/' folders.

                      Currently, what we have is:
                      - tools/ folder contain Bridge's Builder.dll library
                      - build/ folder contains Bridge.targets (which has settings that uses to the DLL above)

                      While this seem to meet your requirements, I am not sure this is at any rate a common practice among NuGet packages to have licenses over those directories. Some suggestions include adding the license file to NuGet package's root directory, nothing too fancy. Actually, that seem to be an active subject on NuGet discussions.

                      Comment


                        #12
                        Having the license in the package root sounds ideal to me - it's still included in the package, but neither in the project (the actual .csproj file) nor in the project files.

                        Personally, I'm not as bothered by additional files appearing in the "Bridge" folder in the file system, but I don't want them appearing in the project in Visual Studio - so including the license file in the "Bridge" folder would not be that bad if it were not referenced by the project. I still think it would be preferable to have it in the package root (and to use requireLicenseAcceptance=true) but I wanted to make clear that, for me, it's the "polluting" of the project that is much worse than extra files appearing in file system. (And, like I said earlier, using .gitignore could only work if the license and / or bat files were in the file system but not referenced by the project).

                        Thanks for looking into this!

                        Comment


                          #13
                          Hello,

                          I've created an specific issue to deal with the license file as we might further analyze the viability of moving it to the package's root folder instead of copying it over into the project every update. It is logged under issue #327 on GitHub.

                          On that issue we should either comply to your request or give you a final response as to why we felt like not moving it out of the project deploy list of files for the time being.

                          Thank you very much for your suggestions, we mean to take serious consideration over all of them to let Bridge.NET be a great and productive software for everyone!

                          Comment


                            #14
                            Sorry for not responding; I don't seem to have had email notifications for the recent posts :(

                            Just to back up geoffrey.mcgill statements, the Apache 2.0 license we adopted for the project has in its 4.a. section the following text:

                            "You must give any other recipients of the Work or Derivative Works a copy of this License"


                            So that's why -- in efforts to follow the rules of the license -- we must provide it with the installed version of Bridge.
                            I understand the desire to include the licence; but I questioning the need to pollute my project with it. I know what the licence is at the time I install it and I know where to find it if I need it. I'm working on my project on a daily basis and having a solution tree full of licences is just clutter. I want to be able to find my code quickly in my project, and the more junk that's there, the more things will appear in search results, etc. when I'm trying to find things. I don't see why you need to put the licences inside the project to meet the criteria posted.

                            I'm not entirely against the idea of putting it in App_Readme, as at least it's kinda out of the way. However, I still do't think that seems like a good place to put these. If an app has an App_Readme folder, it seems like it should contain readmes about the project, and also not be polluted by things from dependencies.

                            But as Bridge creates its own "Bridge" directory, where bridge.json file must be in, would that hurt to have a license file over there?
                            I might be in a minority here, but since my Bridge folder only has a bridge.json in; that's one thing I'd be happy to have in the root and do away with this folder entirely! =D


                            I don't want to drag this out; I don't feel strongly enough that I think it should take up your time. I like to have my projects clean and as free from boilerplate/generated/3rd party files/code as I can, but I know this is a personal thing. This is your project, and you are best place to make decisions for it. We're probably going to have Bridge set up on our CI so that we can get bug fixes quickly if required (or if we need to make our own), so using a custom NuGet that didn't have these files would be fairly trivial :)

                            Comment


                              #15
                              I have removed the clean.bat and deploy.bat files from the NuGet package.

                              Sample .bat files for each are now available as a Gist:

                              clean.bat
                              https://gist.github.com/geoffreymcgi...cbfc5414e19c93

                              deploy.bat
                              https://gist.github.com/geoffreymcgi...38647c442c7a43

                              A note has been added to the beforeBuild and afterBuild config documentation in the Global Configuration KB article which points to the Gist samples above.

                              This closes GitHub Issue #308.

                              I'm still thinking about what to do about the License issue, and will post a comment here once we come to some conclusion.

                              Comment

                              Working...
                              X