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

Header file missing CLSIDs #12

Closed
nmoinvaz opened this issue May 13, 2019 · 7 comments
Closed

Header file missing CLSIDs #12

nmoinvaz opened this issue May 13, 2019 · 7 comments
Labels
bug Something isn't working doc documentation issues feature request feature request

Comments

@nmoinvaz
Copy link

nmoinvaz commented May 13, 2019

The WebView2.h header file appears to be missing CLSID constants. For example, the IE WebBrowser control has the following CLSID_WebBrowser defined:

#ifdef __cplusplus

class DECLSPEC_UUID("EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B")
WebBrowser_V1;
#endif

EXTERN_C const CLSID CLSID_WebBrowser;

However, there are no such CLSID constants defined for WebView2. I'm not sure if this is intended or not. Maybe it is intended if you cannot call CoCreateInstance to create a new instance.

@david-risney
Copy link
Contributor

Thanks for having a look at our API! Yes, our API uses COM style interfaces but does not define any coclasses and doesn't use CoCreate. Instead we use one of the DLL exports to create a root object. Will this make things difficult for you?

@nmoinvaz
Copy link
Author

nmoinvaz commented May 13, 2019

Is the WebView2Loader.dll DLL and its exports intended to be the way to integrate with WebView2 when the API goes live or is it only for this development stage? If it is intended for the go-live stage of this API, it is some what problematic.

Some problems I am encountering:

  • Shipping an additional DLL is problematic for us, as our executable is only a single executable. In other platforms, Linux & Mac, and Windows with IE, it is not necessary to ship separate shared libraries, they are already installed on the system and we dynamically find the one to load and use.

  • It appears that Windows Runtime Component is required to consume the header files? It is possible to consume them without #include <wrl.h>? Only the event mechanism appears to use them. Currently our application is compiled for use with Windows XP so Platform Toolset using v141 is not ideal.

  • I would like to dynamically load/CoCreate the instance of WebView2. If the CoCreateInstance fails on the machine I can fallback to IE and use IWebBrowser2.

@nmoinvaz
Copy link
Author

It also appears that using IIDs such as IID_IWebView2CreateWebView2EnvironmentCompletedHandler do not resolve properly using CINTERFACE and COBJMACROS.

EXTERN_C const IID IID_IWebView2CreateWebView2EnvironmentCompletedHandler;

error LNK2001: unresolved external symbol _IID_IWebView2CreateWebView2EnvironmentCompletedHandler

@david-risney
Copy link
Contributor

  • The current plan is for the end developer to ship that DLL with their app. We'll look into how we might avoid that. I'll open a task for that.
  • WRL shouldn't be required its just very convenient to implement interfaces that have a single Invoke method. You should be able to implement the IWebView2NavigationStartingEventHandler interface manually and pass that in to add_NavigationStarting directly rather than using WRL. I'll open a documentation bug for that.
  • The DLL to include is intended to be very small and to find the right install of Edge (evergreen or BYO) and so is similar to dynamically calling CoCreate. If the Edge browser isn't installed the call can fail, you're get a failure HRESULT back and can fallback to CoCreateInstance of IE.
  • Good point about IID_*. I'm not linking that in. I'll open a bug for that. We missed it since our sample code all used WRL or IID_PPV_ARGS which in turn use __uuidof

@david-risney david-risney added bug Something isn't working doc documentation issues feature request feature request labels May 13, 2019
@nmoinvaz
Copy link
Author

nmoinvaz commented May 14, 2019

  • I think the best scenario would be to have the component installed on the system along-side Edge and possibly available as COM control through CoCreateInstance. I'm curious why have the developer ship the DLL rather than ship with Edge? Maybe there is some requirement I don't know.
  • What is the license of the DLL? Are we able to embed it as a resource and extract and use on-demand?

@david-risney
Copy link
Contributor

  • For the BYO case Edge might not be installed so having a separate DLL is sort of lowest common denominator that works for all scenarios. But long term Edge should be installed and not requiring end developers ship a separate DLL would be much more convenient. I've got a task open to look into that.
  • It is in the nuget package. I am not a lawyer but we would like for apps to be able to ship and use the DLL including I expect in the way you describe. If you don't think that meets what's listed in the license please let me know and we'll look into that too.

Thanks for your feedback, this is great!

@liminzhu
Copy link
Member

Thanks for reporting the issue again @nmoinvaz! This is fixed in the new SDK update. Make sure you update the SDK and use the Canary channel for testing since the Dev channel may not have the necessary fix yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working doc documentation issues feature request feature request
Projects
None yet
Development

No branches or pull requests

3 participants