-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
First time package restore - DllExport is not performed #159
Comments
This is only for old non Sdk-style projects. Modern VS environment processes everything at runtime (EnvDTE) due to construction through intermediate or obj files. Well, I think I understood the problem. In 2017 it was resolved as #62 (comment) Can you check with latest 1.6.x release ? I will look into later. Thanks for the report! Logically temp solution: execute -action Restore before build if no restored packages in folder. |
Confirmed. The problem because of unevaluated property |
@tapika Please confirm solution
|
Planned for 1.7.3 |
* FIXED: Fixed syntax error at token '-' in: IL_002d: ldc.r8 -nan(ind) with "return Double.NaN" Through "Single + Double NaN token patching" option. Issue #158. ``` .field = float32(-nan(ind)) -> 0xFFC00000 .field = float64(-nan(ind)) -> 0xFFF8000000000000 ldc.r8 -nan(ind) -> 00 00 00 00 00 00 F8 FF ldc.r4 -nan(ind) -> 00 00 C0 FF ``` * FIXED: NuGet packages are not visible as installed when DLLExport enabled for project. Issue #152. * FIXED: Concurrency Issue with Parallel Project Builds. Issue #73. * FIXED: Fixed the first phase of the build when restoring. Related issue #159. * FIXED: Fixed VS NuGet PM possible error: "You cannot call a method on a null-valued expression." * CHANGED: Improves package integration. PR #161. - Updated logic for packages through `-pkg-link` key. - Removed `-force` key from the project files if it was pushed together with other commands for manager.
Tested. Restore seems to be now working, but Visual studio intellisense on But I guess to be able to restore DllExport - you need to cherry pick DllExport.bat into your own repository and save it there. Btw, I have some multiple solutions, which are in different folders, which use same project. Btw, if anyone wishes to use cmake for generating project, it's possible to use but |
Please use modern Sdk-style. Then it will be auto re-loaded at runtime. Or consider click on reload button in VS File Modification Detected dialog for legacy project files (non-sdk based): https://youtu.be/okPThdWDZMM?t=96
Yes, repo must contain at least DllExport.bat (~20 Kbytes) before build. But nothing else.
I think you can try to open PR for providing some common solution with custom paths. For cmake and related automation you can consider an available External storage + Export / Recover / https://github.com/3F/DllExport/wiki/DllExport-Manager#external-storage Related issue: #76 (comment) |
By briefly testing DllExport functionality - I've understood that integration into solution is not so standard mechanism - instead of nuget package restore project itself executes
DllExport.bat -action Restore
in$(SolutionDir)
-directory.During first restore + compilation however - the used dll becomes normal dll, without processing
DllExport
-attributes and it's not valid by itself. (This can be checked for example usingDependencies
utility)For second, etc problem disappears - as all required dll's from nuget package are downloaded and processed by Visual studio. This might require solution close / re-open step to make compilation process and intellisense fully functional.
I've tried to solve this, and removed from project
xml tag completely, but kept our own nuget package restore.
DllExport.bat
besides restoring nuget package also generates some of dynamic dlls, which will come intoDllExport.1.7.1\gcache
, which are project specific dlls.I've put into version control
DllExport.1.7.1\gcache
, also following files:Rest of files will be restored by nuget package restore functionality.
and after that even first compilation works correctly.
But with this fix - even first compilation start to work - I suspect msbuild is loading .dlls earlier than you expect - maybe needs to be fixed ?
The text was updated successfully, but these errors were encountered: