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

Added React Native Windows dotNet46 support #684

Merged
merged 39 commits into from Feb 14, 2017
Merged

Added React Native Windows dotNet46 support #684

merged 39 commits into from Feb 14, 2017

Conversation

abodalevsky
Copy link
Contributor

@abodalevsky abodalevsky commented Jan 31, 2017

Added support react-native-windows dotNet
Added example for react-native-windows UWP based
Added example for react-native-windows dotNet based

Project structure:

CodePush.Shared - shared code between UWP and dotNet
CodePush - UWP specific code
CodePush.Net46 - dotNet specific code

For UWP solution it needs to be added the following projects:

  • CodePush.Shared
  • CodePush

For dotNet solution it needs to be added the following projects:

  • CodePush.Shared
  • CodePush.Net46

Examples:

Examples\CodePushDemoApp\windows\CodePushDemoApp.sln the solution contains both examples (UWP and dotNet).

Notes

Example for ARM configuration has not been tested. Since there is no changes in UWP part of implementation, there is low risk of failure.

In this implementation we tried to reuse UWP library as much as possible. The following issues are relevant for both platforms:

  1. ZipFile.ExtractToDirectory is not reliable and throws exception if:
    • folder exists already
    • path is too long (> 250 chars)
  2. Un-zipping is quite long operation. Does it make sense for async?
    • await UpdateUtils.UnzipBundleAsync(downloadFile.Path, unzippedFolder.Path);

@msftclas
Copy link

Hi @abodalevsky, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

internal async Task LoadBundleAsync()
{
// #1) Get the private ReactInstanceManager, which is what includes
// the logic to reload the current React context.
FieldInfo info = typeof(ReactPage)
.GetField("_reactInstanceManager", BindingFlags.NonPublic | BindingFlags.Instance);

#if WINDOWS_UWP
var reactInstanceManager = (ReactInstanceManager)typeof(ReactPage)
.GetField("_reactInstanceManager", BindingFlags.NonPublic | BindingFlags.Instance)
.GetValue(_codePush.MainPage);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more of a question for the CodePush team, but should we just make the fields you need here part of the public API on react-native-windows?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rozele That would be ideal and would help us to avoid being broken by changes, but it's up to you if that's your priority. We do the same kind of reflection on the other platforms, although we would like to at some point in the distant future submit PR's so that we can get rid of it.


namespace CodePush.ReactNative
{
public sealed class CodePushReactPackage : IReactPackage
{
private static CodePushReactPackage CurrentInstance;
private static bool NeedToReportRollback = false;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is suspicious, is this some missing feature, or was it just totally dead code?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was part of @geof90 's original commit (according to git blame). The value is set to true, but never read from. Looks like it was transliterated in to C# incorrectly, maybe? We can file and issue and do a separate PR to fix -- we specifically have user stories in our project for update failure modes that will likely force us to fill missing gaps on that front.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matthargett I suspect the purpose of this is to post to the CodePush server after a rollback happens, so that users can see a record of the number of rollbacks in the CodePush CLI. If you'd like to file an issue and do a separate PR I am fine with that!

private static ApplicationDataContainer Settings = ApplicationData.Current.LocalSettings.CreateContainer(CodePushConstants.CodePushPreferences, ApplicationDataCreateDisposition.Always);
#else
private static ApplicationDataContainer Settings = new ApplicationDataContainer();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new ApplicationDataContainer(); [](start = 59, length = 31)

Are these settings in-memory only then? I think ApplicationData.Current.LocalSettings is persisted across runs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right absolutely! Thanks for this catch.
Fixed in 03af9fc

@abodalevsky
Copy link
Contributor Author

Regarding PCLStorage. I use it for Net46 project only. In fact this doesn't add additional dependency because it is already exists in ReactNative.Net46 project.

In general, probably, it make sense to use PCLStorage for UWP implementation as well. A benefit will be more code shared between UWP & NET implementations. As I mentioned in comments above I tried not to modify existent implementation UWP, as this is not the subject of this PR.

.gitignore Outdated
@@ -150,3 +150,37 @@ captures/

# Remove after this framework is published on NPM
code-push-plugin-testing-framework/node_modules

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you mirror these changes to the .npmignore file, and if possible, could you also leave a comment at the top of this file informing future contributors that they need to do the same?

I'm also assuming there's nothing you want to exclude from the npm package that isn't already listed here, but please add them there if so!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Silhouettes Updated. (Alex is offline for a few hours)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @kevinvangelder! I also added UnitTest project to .npmignore

@richardhuaaa
Copy link
Contributor

@rozele Do you think your and @matthargett's reviews are sufficient to merge this?

@rozele
Copy link
Contributor

rozele commented Feb 9, 2017

@Silhouettes I'll take another pass and then approve.

"run-sequence": "latest"
"run-sequence": "latest",
"tslint": "^4.3.1",
"typescript": "^2.1.5"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason why these were added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing special, just wanted to avoid npm UNMET PEER DEPENDENCY warnings:

npm WARN gulp-tslint@7.1.0 requires a peer of tslint@>=4.0.0-dev but none was installed.
npm WARN tslint@4.4.2 requires a peer of typescript@>=2.0.0 but none was installed

it needs to be handled
*/
throw e;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will screw up the stack trace of the exception (the point where the exception is thrown is recalculated from here). Since this has no net affect on the behavior other, please remove this catch block.

{
throw e; //left here for debug purposes to see the reason of ZipFile failure.
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another case of a catch block with no purpose.

@rozele
Copy link
Contributor

rozele commented Feb 9, 2017

@rihua@microsoft.com one architectural comment about the shared code project. If we were shipping code push as a compiled binary, it wouldn't matter so much, but now users have to add two projects to their react-native-windows solutions to see all code from the code push module. Obviously the shared code approach saves a bunch of duplicate code for WPF. The only other alternative would be to request that a copy of all code be made instead of using a shared project. Just thought I should point this out, as it could impact perceived debuggability for code push users.


In reply to: 278792526 [](ancestors = 278792526)

@rozele
Copy link
Contributor

rozele commented Feb 9, 2017

Other than the final comments I've made, and the general comment about shared projects, this looks good.


In reply to: 278795588 [](ancestors = 278795588,278792526)

@matthargett
Copy link

@rozele we can follow up with a separate PR that creates a NuGet package for CodePush, if you like. Since CodePush isn't like React Native Windows where people may want to extend the core source project with new files, it should probably be a NuGet package regardless of this PR for the best DX.

@richardhuaaa
Copy link
Contributor

I will merge this PR on Monday unless anyone still wants to make changes.

Thanks everyone for the great work and the very informative comments :)

@richardhuaaa richardhuaaa merged commit be96f07 into microsoft:master Feb 14, 2017
@maxim-pop
Copy link

Hi @abodalevsky ,
The Demo App contains a .pfx certificate file (/CodePushDemoApp/windows/CodePushDemoApp/CodePushDemoApp_TemporaryKey.pfx).
Is it possible to remove it from repo? We have compliance issues with storing secrets in code.

@abodalevsky abodalevsky deleted the feature/net46 branch March 6, 2017 08:47
@abodalevsky
Copy link
Contributor Author

Hi @maxim-pop

VisualStudio has generated this certificate by default within the project. In general it should be used for signing the assembly for deployment purposes. But I don't see in code that it is used. Therefore I may assume that for this example the *_TemporaryKey.pfx may be safely removed.

I have created PR #741, please take a look.

@maxim-pop
Copy link

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants