1

I look after a framework which has 3 projects:

Front End UI
    \bin
        \my front end dlls
    \images
        \theimages.png

API
    \bin
        \my API dlls

Database Migrations
    \bin
        \my migration dlls

My setup/structure in IIS is as follow:

Front End UI (Top level IIS Site)
    \bin
        \my front end dlls
        \Database Migrations
            \my migration dlls
    \images
        \theimages.png

    \API (Converted to an App in IIS)
        \bin
            \my API dlls

I would like my nuget package to output to this structure.

Users will create a new blank project in Visual Studio, and add this nuget package. That would give them the structure as shown in the IIS bit above. They will only add a couple of config files to this new project.

In IIS they will then create a new site, point it to Front End, and convert the API folder to an app.

Should be quite an easy setup.

My problem is that I can create a nuspec file, and manually include the API and Migrator files into content\API\bin and content\bin\Database Migrators but the problem then is that the default .gitignore file will exclude those sub bin folders by default and those dlls won't be committed.

I'd really want to prevent having to have the developers tweak the .gitignore file to force inclusion of the API\bin and Database Migrators\bin folders if possible.

Is there a better way to do what I'm doing here?

Cheers,

Albert
  • 1,062
  • 2
  • 13
  • 20
  • Hi Albert, any update for this issue? For now there's no easy way to achieve what you want, could I ask why you want to commit the dlls? As I know, in most of the time there's no need to add the output assemblies into version control... :-( – LoLance Nov 07 '19 at 09:38
  • The situation is that the DLLs I want to commit are not output dlls from this project. They are only needed to run the IIS site. They are also NOT references to this project. So what I'm doing is basically packaging up my whole IIS site, and when developers clone and install the nuget package, they get a working site. The dlls are only copied to the `API\bin` folder on installation of the nuget package, so only I get them in the right location. When cloning, they are not copied again... – Albert Nov 07 '19 at 19:51
  • 1
    Hi Albert, any update for this issue? I met [one issue](https://stackoverflow.com/questions/58838867/nuget-package-silently-adds-back-deleted-files-to-project-directory-not-only-ini/58853799#58853799) in which there's a good package that uses the msbuild targets to do many custom jobs in it, maybe you can get some useful info about how to use target creating packages there. If you're still blocked there, feel free to let me know.. – LoLance Nov 14 '19 at 12:43

1 Answers1

0

Is there a better way to do what I'm doing here?

I'm afraid the answer is negative, by default if you add the solution to source control in Visual Studio, git component in VS will create the .gitignore file in solution directory with default content [Bb]in/ in it. (At least for VS2017+VS2019)

So it always ignore all the bin/ or Bin/ directories in your solution directory. As I know, you have to modify the .gitignore file if you want to include the sub bin folders into source control.

In addition: To be honest, I'm not sure why you need to commit the dlls, I guess you copy the assemblies from the output bin folders of the three projects into content\bin\Database Migrators and content\API\bin, in this situation there's no need to add that sub-bin folder into source control.

And apart from using content\bin or content\API\bin, you may also consider using targets file when creating nuget package. You can specify many actions in that file, and it will execute when building the project which consumes that package. So there's possibility that you can define copy task in that to copy the assemblies from nuget to where you want in project which consumes the package. But this could be much more complex, I don't think it's the better way you want :(

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • Hi, thanks for getting back. I need the dlls committed so that when other developers clone, they get the full setup, otherwise they never get the dlls in the appropriate location (`API\bin` in this example). I'm going to check out the copy targets, and see if I can do a copy operation to the correct location on build, straight from the nuget package location, that may be quite a nice solution since I won't need to commit the dlls, and I won't need to add special rules to the .gitignore file. Thanks for the tip! – Albert Nov 07 '19 at 19:48
  • Hi Lance, I have finally managed to take a look at this again. I am going with the custom build targets route. That was a good idea. I found this SO post which explains it and going with this answer: https://stackoverflow.com/a/30668355/182888. Thanks for checking it out! – Albert Nov 28 '19 at 20:01