Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-build manifest file #58

Closed
david-poindexter opened this issue May 12, 2016 · 4 comments
Closed

Auto-build manifest file #58

david-poindexter opened this issue May 12, 2016 · 4 comments
Labels

Comments

@david-poindexter
Copy link
Contributor

@dazinator not sure if you have looked into this possibility or not, but thought I would at least log it for consideration. I ran across some work being done by XCESS here and thought it was a great idea. It would be nice to not have to manually maintain the manifest file. Your thoughts?

@dazinator
Copy link
Owner

dazinator commented May 12, 2016

Yep this makes sense to me. I have considered auto building the manifest using attributes, and I have created a library here that can be used to programatically build a manifest and then save it to xml.

So for me this definately makes sense as a feature for DnnPackager, i.e during the current packaging task it can:

  1. Inspect the primary output assembly for known attibutes (Like a Module attribute, or a Library attribute etc)
  2. Auto build the manifest based on the information provided by those attributes.

One concern with this approach is that I don't like the idea that you would have to reference the assembly containing these attributes in your module / project, because that means you also have to deploy this additional assembly with your module - when it really is only needed at build time - it's now become a runtime dependency.

As you can imagine, if you have one module installed using 1 version of this attributes assembly, and then you install another module using a slightly later version of that attributes assembly - there can only be one version of it in the bin folder, so something will break in that scenario.

I think there are a couple of solutions to eliminate the runtime dependency on the attributes assembly:

  1. Make the NuGet package add the actual source code files for the attributes to your project - this way they get compiled with your own component and it eliminates the assembly dependency.
  2. Use something like Fody.Weaver to run during build, and clean the attributes from the output assembly. (MSIL manipulation at build time)

Also the amount of attributes that you would need to represent the manifest could be quite a lot.. Would have to think very carefully about the attributes themselves and how to make them simple but effective!

@dazinator dazinator added the idea label May 12, 2016
@dazinator
Copy link
Owner

This is also very similar to how Xamarin projects work for Android applications so it should be kind of familiar for those developers.. You can manually edit the android application manifest, but you can also use attributes to suppliment the manifest data.

@dazinator
Copy link
Owner

Will close this as decided will want to go ahead with this. Read #60 for further info about how I see this working.

@david-poindexter
Copy link
Contributor Author

Thanks @dazinator!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants