This project has moved. For the latest updates, please go here.

Avoid creation of .licenseheader files

Oct 23, 2013 at 10:34 AM
We really don't want these polluting our projects, I can understand how they work well for some, but they don't work for everyone. We have some fields in the header which are user specifc, where %UserName% is not appropiate, and would just prefer to configure users manually with the default header file.

Is this possible in the current 1.4 version?
Coordinator
Oct 24, 2013 at 8:39 AM
Hello Mark!

Let me see if I understand correctly: You'd like the option to create a default license header as a per-user setting (separate file or part of VS-settings) instead of the per-project settings which are supported right now? This user-specific license header would then be used when inserting the licenseheader.

I can see how that would be helpful in some cases. Are you more concerned with the per-user settings or with the fact that there's an extra file linked with each project?

Best regards, Michael
Oct 24, 2013 at 8:51 AM

We don't use %username% as its a meaningless logon Id, however our header template does need the correct user in it. This means every user has their own template using date and time and filename variables, but their own name.

The creation of the licence header file serves no benefit in this scenario, it's actually a problem.

Hope this explains better.

Coordinator
Oct 25, 2013 at 9:53 AM
Thank you for clarifying. Would it be workable solution for you, if we introduced custom properties (e.g. you could then use "%NaturalUserName%") and those properties would be managed via the LicenseHeaderManager settings stored within your VS-Profile? Since this approach would require you to keep the license file, I am wondering if you just need to solve your use case of per-user-settings in the generated license header, of if you are opposed to having a license file template located inside the project.

An even simpler solution would be, if we could just map properties to environment variables. That way, the change would be limited to the property resolution logic and we could offer the use of all available environment variables. Would require us to check out the performance impact of the additional Search&Replaces, but I'd like to know your thoughts on whether that would be an option for providing the natural user name. I.E. would it work for you if you could define your natural user name via a Windows environment variable?

Best regards, Michael
Oct 25, 2013 at 12:33 PM

That would fix the particular problem, but not optimal as our solutions have 30 or so projects and they would all have identical .license header files.

Coordinator
Oct 25, 2013 at 1:40 PM
Edited Oct 25, 2013 at 1:47 PM
I can see that. We're facing the same problem with our own project. Our solution (https://svn.re-motion.org/svn/Remotion/trunk/) contains 74 projects and 5 different license files. We're using Visual Studio's Link-Exisiting-File feature when adding the license file to the project. That way, we only manage each different file once and only need to ensure to add it when we create a new project. You can even use Copy&Paste to add the linked file to each project while keeping the link intact.

As for the why: I'm just trying to keep the complexity of the LHM's code base to a minimum as long as reasonably possible. Makes helping our with new feature requests easier :)

Best Regards, Michael