Short question:
Does the Windows Store allow applications that obtain DLLs or other low-level resources not packaged at compile time? Is there a requirement either by Windows Phone or Microsoft that requires DLLs to be signed? If so, can I use a DLL in my application that is signed by another developer?
Why I'm asking/explanation:
I'm working an an application for Android that allows users to download extensions (like themes), and I'd like to port this to Windows Phone.
I have determined that it's not possible for my app to utilize libraries or other resources of other applications downloaded from the Windows Store. (Please correct me if this is not always the case)
The workaround I'm considering is an in-app download center for other resources specific to this application. I'm wondering if a downloads for this app, specifically DLLs, can be used in my application. These DLLs would be developed by 3rd party developers, so I see that signing might be an issue.
The store specifically prohibits any additions / modifications after the app has been purchased. So although it may technically be possible, they won't certify it.
This makes sense if you think about certification . If they would allow this, it would make certification a moot point, since you would just publish a basic app, and afterwards side-load the uncertified part.
Related
I am new to Windows 8 development, I am having one application which is already running in the i-pad (ios). I want to convert same application into Windows Store apps as this is the client requirement. So do i need to follow the design guidelines for such legacy application? Or I can just follow the same UI which is been developed in i-pad. Is this accepted by Microsoft for Windows Store apps certification ?
Thanks.
According to Microsoft's guidelines, it should not be accepted.
However, some such applications have appeared in the Windows Store in the past, so it's not completely impossible. I would not bet on it though.
And if your app is a game, the guidelines are less strict.
All the user experience (including design) guidelines are referenced here.
And there is a UX checklist to make sure you confort to them.
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.
I want to evaluate the new sandboxing mechanism in Windows 8/Windows Server 2012. I searched MSDN site for any resources but the documentation is extremely scarce. In comparison with FreeBSD Capsicum documentation, the one provided by Microsoft is just unusable.
How are we supposed to build robust sandboxed apps? Are the sandboxing APIs intended for metro style apps only?
I'm not sure what you mean by "sandboxing APIs". All "metro" (Windows 8 UI Applications) are sandboxed. I'm not aware of any way to sandbox desktop applications in the same way. See here.
Metro apps are pretty tightly sandboxed, and apps submitted to the
Windows Store need to declare many types of capabilities that they use
— not unlike Google Play's permissions list.
. . .
Windows 8 features a specific SDK for Metro style apps . . .
A quick explanation of capabilities: There are certain potentially sensitive things that you can do on a user's machine, such as access the Pictures library or use the webcam. If an app wants to do these things, the developer must declare a capability in the app's manifest. Then, when users download the app from the Windows Store, they can clearly see if the app is using any of this functionality. More info and a list of all of the capabilities is provided at App capability declarations.
Regarding sandboxing, there is some information at http://msdn.microsoft.com/en-us/library/ie/hh673561(v=vs.85).aspx. Yes, Metro-style apps are sandboxed in a way that desktop apps are not.
There is a whitepaper discussing security in Windows Store apps built with HTML5 at Secure development of Metro style apps with HTML5. There are also some common security scenarios documented.
We are creating a WCF service with a companion client DLL (.Net) that we will be delivering to a user's GAC via a web page. The DLL knows how to communicate with and how to interface with the service, and will allow the web page to communicate with the WCF service via client-side Javascript calls. The user's machine will be executing the DLL's functionality, not the server. With it data will be transferred to the target server.
This works in theory (and practice) over our internal network. The network is, of course, in a trusted zone so there are no problems with delivery, GAC install and DLL utility. The client-server pair works as expected. We can download the .Net DLL with an object tag, install it in the GAC and use it easilly.
In order for an internet user to be able to download the client .Net DLL however there are security procedures that need to be put in place. We do not have the expertise yet to know exactly what they are, but we are aware that we will need to at least sign the DLL with a trusted certificate. Beyond that, we are unsure.
The question then is what do we do from here?
Give the assembly a strong name (sn.exe - etc)
Create a Windows Installer Project from Visual Studio that will add your custom assembly to the target machine's GAC. (Right click File System on Target Machine | Add Special Folder | Global Assembly Cache folder). Let users download your installer from your web page, probably the most painless way instead of forcing something via the browser.
I have a UI hosted on a webpage. I'm able to run the control on the server hosting it, but when I attempt to run it from other machines on the intranet, only some of the required DLLs make it to the client.
What direction can I take to investigate why this is happening?
I don't think an ActiveX control copies DLL's to the client. More likely the clients already had some of the DLLs. You'll need to install the additional DLLs somehow (as a downloadable installer or using custom code). You may run into permissions issues trying to install DLLs via a web page.