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

Automatic restoring package via msbuild #62

Closed
3F opened this issue Dec 24, 2017 · 2 comments
Closed

Automatic restoring package via msbuild #62

3F opened this issue Dec 24, 2017 · 2 comments
Labels
bug ⛶ user-build End user projects using IDE, MSBuild, CMake, ... and related
Milestone

Comments

@3F
Copy link
Owner

3F commented Dec 24, 2017

Found the following bug for v1.6-RC (18a4d4d) when restoring package via msbuild tools (VS works fine).

After removing package from local storage (.\packages by default):

msbuild <sln> /t:Build

Will restore package correctly but the tool will not process anything for exports.

@3F 3F added this to the v1.6 milestone Dec 24, 2017
@3F
Copy link
Owner Author

3F commented Dec 24, 2017

hmm, yes of course, the problem because of Import sections.
It just will be processed in first step by msbuild analyzer before any other elements.

Therefore:

  1. Condition="Exists(...pkg will ignore this section.
  2. Exec Condition="('$(DllExportModImported)' != 'true' ... will process restoring.
  3. And finally nothing, because we have no targets for the first build from net.r_eg.DllExport.targets because of inactive node.

The second build will evaluate step 1 -> step 2 will be ignored -> and step 3 will be finally processed because of chain with BeforeTargets="PostBuildEvent"

well, need to think because the msbuild may process Import sections only in the first pass to evaluate all its possible nodes :( this is an old specialty, just forgot about this.

@3F
Copy link
Owner Author

3F commented Dec 25, 2017

I've solved this through MSBuild task and 2-pass self-building - f623474

The is easiest and more right way because of mechanism which evaluates the Import sections only in the first pass as I already said above.

But the main idea is that: we still have 1(one) pass-builds because of intermediate same obj files.
We'll just skip 2-pass, but now we'll have same environment with already evaluated nodes from first-pass.

Pros: we don't need to prepare all required properties and targets for options with custom using the our targets.

That is:

* 1-pass ---> build/rebuild -----> binaries ------> finalization
* 2-pass ---> skip for new build ---\--> upd.env -----/

well, time will tell...

Note:

  • 2-pass is possible only when pkg does not exist. Thus, for any future problems (I hope I've foreseen everything :) but...) just use -action Restore it will activate Import node and will evaluate $(DllExportModImported) as true that's finally deactivates this solution.
  • It works for Build, Rebuild targets. For Clean it will be ignored.

3F added a commit that referenced this issue Dec 29, 2017
* NEW: The new embeddable lightweight manager for distribution via MvsSln & GetNuTool projects. Issue #38.
       Based on hMSBuild logic and includes GetNuTool core v1.6.1.

       Now you shouldn't use standard nuget clients anymore:
       https://www.youtube.com/watch?v=9bYgywZ9pPE

       Quick start: https://www.youtube.com/watch?v=sBWt-KdQtoc
        ==============================
        DllExport -action Configure
        ==============================

       Package from nuget.org already contains manager, but you can also get it directly.
       Latest manager: https://3F.github.io/DllExport/releases/latest/manager/
       ~18 Kb text-based embeddable batch-script that does not require powershell and dotnet-cli.

       Automatic restoring still is available but you can also use: `DllExport -action Restore`
       All available features: `DllExport -h`

       Direct links to remote package (without nuget server) via `-pkg-link {uri}` key. Issue #53.
       NuGet Server by default: nuget.org.

* NEW: The new Wizard (configurator via MvsSln). To easy configure your projects in any place. Part of Issue #38.
       MvsSln v2.0: https://github.com/3F/MvsSln

* NEW: Added support of empty/global namespaces - Issue #47.
       Use `Direct-Mod` if Cecil will not process this correctly.

* NEW: Implemented another storage for configuration: '.net.dllexport.targets'. Issue #49.

* NEW: New settings for configurator (Wizard):
        * Path to custom ILAsm.
        * Flag to keep intermediate Files (IL Code, Resources, ...).
        * Timeout of execution in milliseconds.

* NEW: Implemented automatic checking existence of a correct exported proc via Conari. Issue #55.
       Wizard controls it via `$(DllExportPeCheck)`:
        * 0x01 bit - Will check count of all planned exports from final PE32/PE32+ module.
        * 0x02 bit - Will check existence of all planned exports (IL code) in actual PE32/PE32+ module.

* NEW: Implemented PE32/PE32+ Viewer to check manually available exports from final modules. Issue #55.
       New key for manager:
        ```
        -pe-exp-list {module} - To list all available exports from PE32/PE32+ module.
        ```

        Sample:
        ```
        DllExport -pe-exp-list bin\Debug\regXwild.dll
        ```

* FIXED: Fixed target platform detection. Issue #34.
         Details: #34 (comment)

* FIXED: Fixed problem when the Post-Build event is triggered before our tool. Issue #35.
         Use this if still is needed:
         ```
         <Target Name="PostBuildEventBeforeDllExport" BeforeTargets="DllExportMod">
            ...
         </Target>
         ```

* FIXED: Fixed generation of exp + .lib via MS Library Manager for VS2017. Issue #37.
         Now it also includes processing through VsDevCmd & VcVarsAll initializer scripts.
         Use the folowing msbuild properties to override values by default:
         * $(DllExportVcVarsAll); $(DllExportVsDevCmd)

* FIXED: Fixes possible problem with multiple properties that contains *Undefined* word,
         e.g.: *Undefined*\path1;C:\path2 ...

* CHANGED: Added information about finding lib tool. Issue #44.

* CHANGED: UI. Selected platform now affects to all configurations of project instead of active as before.

* CHANGED: Now nuget package does not contain library in `lib/.../` Details in #36.

* CHANGED: Now we also distribute .zip package for work through our manager etc.
           https://github.com/3F/DllExport/releases

* NOTE: How to avoid EXP0014: RunIlAsm. The library manager still cannot be found.
        https://www.youtube.com/watch?v=zUejJ4vUPGw
        Related Issue #44

* NOTE: Quick start (Configuring, Automatic restoring, Pe-Viewer):
        https://www.youtube.com/watch?v=sBWt-KdQtoc

* NOTE: The latest text-based manager:
        https://3F.github.io/DllExport/releases/latest/manager/

           Other versions you can find from GitHub Releases:
           * https://github.com/3F/DllExport/releases

           Or get it from nuget packages starting with v1.6+

* NOTE: PE-features via Conari v1.3.0 https://github.com/3F/Conari

* KNOWN: Bug when - "Build successful but methods are not exported." Issue #59
         For today, anyone else may also try to use https://github.com/3F/Conari to avoid similar @Genteure's problem.

* DIFF(v1.6-RC):

    * FIXED: Wizard. Fixed incorrect layout for zh_CN Simplified Chinese (Thanks @Genteure). Issue #61
    * FIXED: Fixes automatic restoring the package via msbuild. Issue #62
@3F 3F closed this as completed Dec 29, 2017
@3F 3F added ⛶ user-build End user projects using IDE, MSBuild, CMake, ... and related and removed ⛶ msbuild labels Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug ⛶ user-build End user projects using IDE, MSBuild, CMake, ... and related
Projects
None yet
Development

No branches or pull requests

1 participant