missing automation options

[davidsanda]

It would be awesome, if the projects and options to configure them could be entered via command line to allow for greater automation.

[3F]

Actually, I was already thinking about this through ~Install/Remove key: https://github.com/3F/DllExport/blob/master/Wizard/ActionType.cs#L42

So I will consider this later anyway, but I'm still not sure about elegant way to manage this.

The one of the problems is selecting specific projects. Don't forget, it may be 1, 2, 7, 20+ projects in one solution. Thus you should provide list of id or name or path, probably together with pattern via wildcards/regexp. Then we can provide options, but for example, lot of the same for two or more related projects, ughm ... we should also to think how to avoid this excess:

~

• -Install {guid-1} {cfg_format}; {guid-2} {cfg_format}; {guid-3} {cfg_format}; ...
• -Remove {guid-2}, {guid-3}

or it may be only through external file like -Install {cfg.xml}, or via some aggregation ~ {part_of_cfg1}:{guid-1},{guid-2};
need to think for different cases

So please also suggest your preferences.

[davidsanda]

Hi, thank you for responding. I think configuration file is fine. guid is not too useful, i would go with just the project names. regexp/glob string1 - cfg1 regexp/glob string1 - cfg1 It would save a lot of time and eh discontent on the cmake rebuilds :)

…

On Mon, Jun 11, 2018 at 5:46 PM, Denis Kuzmin ***@***.***> wrote: Actually, I was already thinking about this through ~Install/Remove key: https://github.com/3F/DllExport/blob/master/Wizard/ActionType.cs#L42 So I will consider this later anyway, but I'm still not sure about elegant way to manage this. The one of the problems is selecting specific projects. Don't forget, it may be 1, 2, 7, 20+ projects in one solution. Thus you should provide list of id or name or path, probably together with pattern via wildcards/regexp. Then we can provide options, but for example, lot of the same for two or more related projects, ughm ... we should also to think how to avoid this excess: ~ - -Install {guid-1} {cfg_format}; {guid-2} {cfg_format}; {guid-3} {cfg_format}; ... - -Remove {guid-2}, {guid-3} or it may be only through external file like -Install {cfg.xml}, or via some aggregation ~ {part_of_cfg1}:{guid-1},{guid-2}; need to think for different cases So please also suggest your preferences. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ajnxu7MB2zUfp-ekNrdBriyaY5pEKQ5qks5t7pC6gaJpZM4Uh7DO> .

[3F]

@davidsanda, another important things that I forgot to say:

Neither the project name (I mean $(ProjectName)) nor the Guid ($(ProjectGuid)) cannot guarantee anything because it's optional properties at all.

Therefore, by default (without user's actions) only relative path to project file (.csproj, .vcxproj, ...) is an unique 'ident'. We can also use the Guid number from .sln definition, but this is another value and story at all.

This is official/original internal logic in MS libraries when VS or msbuild works with any projects (searching, loading, parsing, etc). MvsSln follows this rules with some additions, but anyway ...

So basically, seems like, we need to implement list only via relative path to project files. Please do not hesitate to comment if someone may have some problems for this way.

[3F]

/draft

option 1 - *only through configuration file

• -Install mycfg.xml
  • only through file - means that we'll not reserve some place for future console commands like -Install path_to_project_file {...} or for any its subcommands-Install -project path_to_project_file {...}
• Same format as for .net.dllexport.targets file - Implementation of the external .net.dllexport configuration file #49 (comment)
• This also supports properties by default and properties for specific projects:

...
<PropertyGroup Label="Default values to all other unspecified projects">
  <DllExportNamespace>System.Runtime.InteropServices</DllExportNamespace>
  <PlatformTarget>x86</PlatformTarget>
  <DllExportOrdinalsBase>1</DllExportOrdinalsBase>
</PropertyGroup>
<PropertyGroup Condition="..." Label="Specific option only for ClassLibrary2\ClassLibrary2.csproj">
  <DllExportNamespace>net.r_eg.DllExport</DllExportNamespace>
  <DllExportDDNSCecil>false</DllExportDDNSCecil>
  <PlatformTarget>x64</PlatformTarget>
  <DllExportOrdinalsBase>0</DllExportOrdinalsBase>
  <DllExportGenExpLib>false</DllExportGenExpLib>
  <DllExportOurILAsm>false</DllExportOurILAsm>
  <DllExportLeaveIntermediateFiles>true</DllExportLeaveIntermediateFiles>
  <DllExportTimeout>60000</DllExportTimeout>
  <DllExportSkipOnAnyCpu>false</DllExportSkipOnAnyCpu>
  <DllExportILAsmCustomPath>$(SolutionDir)bin\</DllExportILAsmCustomPath>
</PropertyGroup>
<PropertyGroup Condition="..." Label="Use default values for ClassLibrary4.csproj from global section" />
...

• The identifiers should be exactly as an relative path to project files.
• Support of wildcards or regex in identifiers.
• Easy to implement because of similar logic as for mentioned .net.dllexport.targets
• -Remove mycfg.xml vice versa.

option 2 - under .net.dllexport.targets

Basically we already have optional external configuration file. Thus we can try to combine this file for both purposes:

• Extend its identifier with an relative path in addition to Guid. See Label attr.
• Implement updating project files for Install, Remove keys.
• Allow global/default properties. Or how about just to configure it once via GUI.

[davidsanda]

This is perfect. Path to project file is a logical choice.

…

On Mon, Jun 11, 2018 at 11:28 PM, Denis Kuzmin ***@***.***> wrote: draft 1 - *only through configuration file - -Install mycfg.xml - *only* through file - means that we'll not reserve some place for future console commands like -Install path_to_project_file {...} or for any its subcommands-Install -project path_to_project_file {...} - Same format as for *.net.dllexport.targets* file - #49 (comment) <#49 (comment)> - This also supports properties by default and properties for specific projects: ... <PropertyGroup Label="Default values to all other unspecified projects"> <DllExportNamespace>System.Runtime.InteropServices</DllExportNamespace> <PlatformTarget>x86</PlatformTarget> <DllExportOrdinalsBase>1</DllExportOrdinalsBase> </PropertyGroup> <PropertyGroup Condition="..." Label="Specific option only for ClassLibrary2\ClassLibrary2.csproj"> <DllExportNamespace>net.r_eg.DllExport</DllExportNamespace> <DllExportDDNSCecil>false</DllExportDDNSCecil> <PlatformTarget>x64</PlatformTarget> <DllExportOrdinalsBase>0</DllExportOrdinalsBase> <DllExportGenExpLib>false</DllExportGenExpLib> <DllExportOurILAsm>false</DllExportOurILAsm> <DllExportLeaveIntermediateFiles>true</DllExportLeaveIntermediateFiles> <DllExportTimeout>60000</DllExportTimeout> <DllExportSkipOnAnyCpu>false</DllExportSkipOnAnyCpu> <DllExportILAsmCustomPath>$(SolutionDir)bin\</DllExportILAsmCustomPath> </PropertyGroup> <PropertyGroup Condition="..." Label="Use default values for ClassLibrary4.csproj from global section" /> ... - Easy to implement because of similar logic as for mentioned .net.dllexport.targets - -Remove mycfg.xml vice versa. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjnxuzfJMwnqRkaSZ3l8bUiQll7Pyf8jks5t7uDrgaJpZM4Uh7DO> .

[3F]

Good, I've plan to implement this feature via file and seems under an existing .net.dllexport.targets @davidsanda, temporarily try to use this external storage for your settings. I think this is also suitable for your case. 12.06.2018 12:36, davidsanda:

…

This is perfect. Path to project file is a logical choice. On Mon, Jun 11, 2018 at 11:28 PM, Denis Kuzmin ***@***.***> wrote: > draft 1 - *only through configuration file > > - -Install mycfg.xml > - *only* through file - means that we'll not reserve some place for > future console commands like -Install path_to_project_file {...} or > for any its subcommands-Install -project path_to_project_file {...} > - Same format as for *.net.dllexport.targets* file - #49 (comment) > <#49 (comment)> > - This also supports properties by default and properties for specific > projects: > > ... > <PropertyGroup Label="Default values to all other unspecified projects"> > <DllExportNamespace>System.Runtime.InteropServices</DllExportNamespace> > <PlatformTarget>x86</PlatformTarget> > <DllExportOrdinalsBase>1</DllExportOrdinalsBase> > </PropertyGroup> > <PropertyGroup Condition="..." Label="Specific option only for ClassLibrary2\ClassLibrary2.csproj"> > <DllExportNamespace>net.r_eg.DllExport</DllExportNamespace> > <DllExportDDNSCecil>false</DllExportDDNSCecil> > <PlatformTarget>x64</PlatformTarget> > <DllExportOrdinalsBase>0</DllExportOrdinalsBase> > <DllExportGenExpLib>false</DllExportGenExpLib> > <DllExportOurILAsm>false</DllExportOurILAsm> > <DllExportLeaveIntermediateFiles>true</DllExportLeaveIntermediateFiles> > <DllExportTimeout>60000</DllExportTimeout> > <DllExportSkipOnAnyCpu>false</DllExportSkipOnAnyCpu> > <DllExportILAsmCustomPath>$(SolutionDir)bin\</DllExportILAsmCustomPath> > </PropertyGroup> > <PropertyGroup Condition="..." Label="Use default values for ClassLibrary4.csproj from global section" /> > ... > > > - Easy to implement because of similar logic as for mentioned > .net.dllexport.targets > - -Remove mycfg.xml vice versa. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#76 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AjnxuzfJMwnqRkaSZ3l8bUiQll7Pyf8jks5t7uDrgaJpZM4Uh7DO> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADGJ_QIyroTKWzwm0SxSmPpumzax-0-eks5t74uOgaJpZM4Uh7DO>.

[3F]

David, I implemented features for additional automation via new actions:

• -action Export - To export configured projects data.
• -action Recover - To re-configure projects via predefined/exported data.
• -action Unset - To unset all data from specified projects.

For all cases will be used same .net.dllexport.targets file inside solution directory as for -action Configure with external storage.
So it can be easily configured and distributed beyond project files.

I implemented exactly Recover & Unset keys because it still uses .net.dllexport.targets as an external storage.
Therefore, you can also recover broken/avoided references with projects in the same manner as their removing without affecting on .net.dllexport.targets

For example:

DllExport -action Unset

Now your projects has been cleaned from our tool. But .net.dllexport.targets still is available for something.

DllExport -action Recover

Will recover one or more missed references from this file. For non-configured solution you can consider it as an Import feature.

But some note:

• Before using -action Recover, you need, either configure it again via -action Configure to update new format of this file or command -action Export that will replace old data. The required data is already presented in the old file, but I don't want to complicate the logic.

Check this out. 662cb35 / build-90

I'll plan to release public 1.6.1 after #59. Hope for today, or tomorrow :)