I had faced some strange behavior while using "broadFileSystemAccess" capability during my app development, i.e.
I'm using above mentioned capability to access entire file system and my app's both min and max version I kept ver 17134 (RS4), and below API's are throwing access denied exceptions in spite of declaring broadFileSystemAccess capability.
The API's are listed below:
ZipFile.CreateFromDirectory - From System.IO namespace
Refer https://github.com/siddhu10/Zipping.git for a sample example which fails for above API.
DownloadFileAsync from FluentFTP - 3rd party lib from nuget
Refer https://github.com/siddhu10/FileTransfer.git for a sample example which fails for above API.
Imp Note: The observation is above API's fail only when min ver is also 17134 (RS4) and higher versions. These API's work when min version is kept 15063 and lower versions.
Kindly help resolving above issues.
The way .NET handles brokered file paths changed in RS3 as part of the .NET Standard work. Prior to RS3, the System.IO types would try to use the WinRT APIs under the covers to access brokered files, which worked as long as the user had granted the app access.
Starting in RS3, the APIs changed to just use the raw Win32 APIs (as part of the standardization effort). There are now Win32 APIs that can access brokered locations, but due to a sequence of unfortunate events these aren't the APIs .NET is using.
As long as your min-ver is less than RS3, you'll get the older behavior (but not full .NET Standard 2.0 support).
As of now, the only way to access brokered locations if your min-ver is RS3 or higher is via WinRT APIs or Win32 FromApp APIs. And since broadFilesystemAccess is in RS4, I'm afraid you can't use it with the System.IO APIs.
If you need to use .NET APIs then you will need to set the minver to RS2 or lower and then ask the user to pick a folder with the FolderPicker. You can then use the FutureAccessList to ensure you have ongoing access to the location.
The problem is that the broadFileSystemAccess capability applies only to the new Windows.Storage APIs in UWP. The classic File IO API you are using are not allowed to access.
You can verify this in the docs. This means you will either have to replace the code with alternatives that use the new APIs or copy the files you need to use to a location that is accessible to the classic APIs like ApplicationData.Current.LocalFolder.
I guess the conclusion here is that .Net Standard file access model (System.IO namespace) is completely broken for UWP apps and there is absolutely no way to make it work. I hoped that broadFileSystemAccess would fix that, unfortunately that is not the case. Hope this will be fixed soon.
Related
My app was rejected due to this ,Please help me to resolve this .This issue is new to me .
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:
"_IOObjectRelease, IOServiceGetMatchingService, IOServiceMatching
The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change. Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
Next Steps
If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third-party libraries are calling these APIs.
Resources
For information on the "nm" tool, please review the "nm tool" Xcode manual page. If there are no alternatives for providing the functionality your app requires, you can file an enhancement request.
Thanks in Advance !!!
I have a "proof of concept" piece of work that crosses over into some unfamiliar territory. I have some experience on J2EE technologies. I'm tasked with connecting an EFTPOS machine to an web application. I am planning to use applet to interact with dll. dll will be running on the client side.
I need to interact with one dll from web application. Please provide me any guidance on this, as I am new to it. I tried interacting with dll from standalone java program, but not able to connect from web application. Any sample codes will be very helpful for me.
Yes that is perfectly possible with an applet. I "connected" an electronice signing device before and it was working very well. Depening on what kind of .dll we are talking about here you need to do the following things:
1.) Create a java access layer / interface for your dll, so that you are able to call the dll functions from java. Depending what kind of dll we are talking about there are several possibilities. The base technology is JNI which is however quite cumbersome to use but luckily there are much more convienient ways out there:
use JNA (if it is a C dll)
use Jacob (if it is a COM component)
use bridj (if it is a c++ dll. You may try swig but haven't used that, so can't tell)
2.) Put your dll inside a jar file and distribute it alongside your applet. How this works is quite nicely described in the jacob project which provides an example for that. You can find it in the source package under jacob-1.17_src.zip\jacob-1.17\samples\com\jacob\samples\applet The example describes the JNLP way to access a native library which will work above java version 1.6.0_10. If you have to use a lower version for some reason, it is also possible but is slightly more tricky...
3.) One more side note: Since the latest available java version (1.7.0_51 or 1.6.0_71) due to security, some rules have been added or tightened for java applets. Now you have to sign your applet with an official certificate and set the right attributes/properties in the manifest, jnlp files. But this has been discussed in great detail here so just search for it. I would probably use a slightly older version for development and if that is working, figuring out how to make it work in the latest java version...
4.) Regarding the interaction part there are also several possibilities. Your Java Applet can call jscript methods from the website it is running in (or also the other way around) or the applet directly communicates with your server. You have all possibilities on that front...
So I have this bit of a project planned for Windows Store and Android. Basically, a networking multi-tool coupled with a scripting engine to implement protocols and behavior. Ideal uses being things like "my embedded device uses this simplistic network protocol. I'd like to quickly prototype a way to control it from my tablet".
It's my understanding that the Android market should have no problem with this. However, the Windows Store policy includes a vague clause concerning remote code execution
3.9 All app logic must originate from, and reside in, your app package Your app must not attempt to change or extend the packaged content
through any form of dynamic inclusion of code or data that changes how
the application interacts with the Windows Runtime, or behaves with
regard to Store policy. It is not permissible, for example, to
download a remote script and subsequently execute that script in the
local context of your app package.
Of course, the scripting engine will be sandboxed and such and should be "safe"(completely intepreted, no reflection), but does it violate this policy?
If you build in your scripting engine, and only run local scripts, you will be good. However, if you were thinking to have a repository of scripts that could be downloaded and subsequently run, that would be in violation of the policy as we understand it.
Unfortunately I don't think anyone but someone on that team can answer that (or someone with direct experience in that) because of the closeness to the legal language. Have you tried the Windows Store Appl Publishing forum at: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/threads
In the context of scripting engine example given, unless the app modifies the scripting engine after deployment on user's system such that the representation of protocol/behavior (the script artifact's format) is made to change then it'll be policy violation. Its as if you submit Python interpreter, and at some point in time it abruptly moves onto interpreting ecmascript.
Is there any SDK available to convert MS word and Excel files to PDF ? I wan to do it on Web Server at run time. Im using VS 2010, .Net Framewrok 4.0
I looked into MS interop assembly but then this artical pushed me back http://support.microsoft.com/kb/257757
is there any thirdparty tool/SDK/Service available that will do that at runtime?
Check out iText, there is a Java and C# library however I think the .NET library is not free. http://www.itextpdf.com/
If you are after perfect conversion then there is no real solution available / viable other than somehow involving Office. Plain MS-Interop is a nightmare and very unreliable, but there are good third party solutions available.
Give the Muhimbi PDF Converter Services a look. It installs in your environment as a scalable and robust Windows Service and has specifically been designed for use from server based applications such as ASP.NET.
It comes with a friendly web services based interface that allows it to be used from most modern environments such as Java and .NET. It supports all common as well as some not so common file formats. Watermarking and PDF Security is included as well. If you have SharePoint in your environment then a SharePoint optimised version is available as well.
Disclaimer, I have worked on this product so the usual disclaimers apply. Having said that, it works great.
You can use the Save as function which is already available in Microsoft.Office.Interop
doc.SaveAs(ref FileName, Microsoft.Office.Interop.Word.WdSaveFormat.wdFormatPDF);
I need to know which permissions are requested by an assembly. With permission I mean for example the WebPermission
Background: I have a service which executes plugins in a sandbox. These plugins are restricted with code-access security. For example: they aren't allowed to access the file system or the registry. Networking is restricted to only http, ...
I would like to analyze these plugins in our build-process to ensure that only classes are used, which are covered by the granted permissions.
In .NET 2.0 through 3.5, the permcalc tool would have allowed you to extract a "best guess" minimum permission set for an assembly. However, the tool has not been updated for .NET 4.0 where, for example, the new transparency approach would have a considerable impact on the analysis results.
AFAIK, there is no permcalc substitute (Microsoft or third-party, commercial or free) available for .NET 4.0. In the absence of such a tool, your best bet for verifying the plug-ins would probably be an appropriate set of integration tests run under the runtime permission set.