-
Notifications
You must be signed in to change notification settings - Fork 243
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
Compile-AppInNavContainer symbol files for Microsoft_Application are missing customization #325
Comments
The Test symbols are special I think - doesn't VS Code get these into a specific file? |
Test symbols shall not be handled in the special way if the objects are imported into BC using generatesymbolreferences (and that is the case in my example). If the line |
I am having a hard time reproing this - I might be doing something wrong??? |
This could be divided into two issues:
For number 2 i have filed a support request to Microsoft. |
I just talked to the guys from the modern dev team.
Which is one symbols app of each. |
Same as you:
But this doesn't matter, even though it only lists ONE application it obviously returns different symbols files depending on which version you add as a parameter.
This is the problem with Compile-AppInNavContainer, it uses the version nr it gets from
So what we have is that it returns different symbol file depending on which paramater you use in the download symbols call. Is this right, I don't know thats for you (MS) to decide ;) Until it is decided I did the workaround for Compile-AppInNavContainer that used the version in App.json instead of the ones the server says it has. |
I can just confirm @NAVFreak observations, with the following additions: In order to reproduce the above results I have just instatiated the following container: I also tested it without enabledSymbolLoading and the VS Code downloaded original Microsoft_Application_13.3.27233.0.app as expected. |
I have been investigating this and now I know what goes wrong. The right fix is to ensure that the applicationVersion number in the database is correct.
but this takes a lot of time during container creation.
That is fast and will cause Compile-AppInNavContainer to use the app.json version number. |
Thanks @freddydk for the suggested workaround. It works well for me ... |
The workaround works, but we need to do something with Compile-AppInNavContainer. I still think that it doesn't use the application version in app.json is a bug. Because that is what compiler in VS Code does. |
Have been busy - I will fix this in the right way in the next version of NavContainerhelper |
Shipped in 0.5.0.5 |
I am using container with enabled symbol loading and imported Test Libraries.
The app.json does not include Test.
Compilation via Compile-AppInNavContainer is failing on the missing test libraries references.
I have checked it a bit further:
When manually downloading symbols via VS Code the Microsoft_Application includes the test libraries.
When using Compile-AppInNavContainer the downloaded Microsoft_Application is missing the test libraries.
Version of the Microsoft_Application also differs in those scenarios.
I assume this is caused by versionText parameter in Invoke-RestMethod which in VS Code is taken from app.json - as it is (13.0.0.0).
Whereas in Compile-AppInNavContainer the versionText for Application seems to be overriden by Version provided by Get-NavAppInfo -SymbolsOnly section (13.0.26556.0 in my case of CU2)
The text was updated successfully, but these errors were encountered: