Attempting to submit a Windows Phone Silverlight 8.1 app to the store. Solution has several projects, including a Models, Contracts and a Shared DLL. These 3 projects/dlls are failing the Windows App Certification Kit tests with:
File XXX.Shared.dll has failed the NXCheck check
File XXX.Contracts.dll has failed the NXCheck check
File XXX.Models.dll has failed the NXCheck check
Microsoft say the problem is a Security threat issue, because these dlls are running code that is stored in a data segment.
The suggested resolution from Microsoft is to add the /NXCOMPAT switch to the Linker options, however, I do not have a Linker page in the properties in any of the 3 offending projects. I've tried adding this to the compilation symbols, but no change.
These DLLs are low payload - they contain not much more than POCO data objects, interfaces and a few static methods. I've built a new default blank Windows Phone app and added these projects to the Solution. If I reference any one of these projects in the main phone app project, the certification fails with the same result.
So the problem is definitely isolated to these 3 projects. There are other projects of the same type included in the solution, but these do not exhibit the same problem.
Does anyone have any ideas as to what these DLLs could contain which causes this Binary Analyzer failure?
I've compared compiler / build options and checked the project properties etc, but can't see any obvious differences.
This was due to a post-compile Build Event referencing an obfuscation library in each of these projects. Solution was to remove it as the library was third party.
Related
I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.
I've found a topic describing NullReferenceException in Windows Phone designer, however I believe this is a somewhat different issue, since it happens in all platforms and not related to MvvmCross plugins.
Designer (VS2012, Store/WP8/WPF apps) works fine for earlier versions of MvvmCross. I tried to compile a version that corresponds to 3.0.6 NuGet packages, and I can see that design-time model is loaded in all platforms.
Recent MvvmCross version causes all designer to raise NULL reference exception ("Object reference not set to an instance of an object") on all platforms.
Attempt to debug a VS instance didn't help: the call stack doesn't say much, and there is no MvvmCross code there.
The error is not related to the actual view/view model: I can remove all controls from the view, and the error is stil raised. The view model constructor code is never reached.
So it looks like there's some MvvmCross code (not from MvxView) that is unsuccessfully executed in at design-time. I wonder if this is a known issue and/or if there is a workaround to get designer work.
UPDATE. I created a GitHub issue with steps to reproduce the problem: https://github.com/slodge/MvvmCross/issues/347
This question moved to GitHub where there was lots of discussion and a few samples - https://github.com/slodge/MvvmCross/issues/347
From these samples, I believe we concluded the Nuget release 3.0.8.1 :
supports time data based on Blend-generated XML data files
supports design-time data based on simple C# classes
does not support design-time data where the data uses MvvmCross MvxViewModel as a base class
It isn't entirely obvious that developers should want to do the third thing (designtime data isn't real data?), but given that the overall MvvmCross manifesto broadly speaking aims to enable developers and to give them choice, then future MvvmCross will make this easier in the future.
In the meantime, if anyone wants to initialise objects at design-time, then there are a few helper classes around to enable this.
For example, the color plugin (and a small part of MvvmCross IoC) can be made available in the design-time environment using the MvxColorDesignTimeHelper - see:
https://github.com/slodge/MvvmCross/issues/323 (linked to MvvmCross throws NullReferenceException in Windows Phone Designer)
https://github.com/slodge/MvvmCross/blob/TibetBinding/Plugins/Cirrious/Color/Cirrious.MvvmCross.Plugins.Color.WindowsPhone/MvxColorDesignTimeHelper.cs
https://github.com/slodge/MvvmCross/blob/TibetBinding/CrossCore/Cirrious.CrossCore.WindowsPhone/Platform/MvxDesignTimeHelper.cs
I understand the concept behind MDIL and the role of cloud compilation of CIL -> MDIL ..
My question is, what happens when we remove the "cloud compilation" story , how or what does the MDIL compilation step for enterprise deployed windows phone apps?
Is it the CrossGen.exe that runs as part of VS when F5ing in "Release" mode? Is the XAP that we deploy in our "enterprise" store in this case a MDIL XAP or is it the CIL XAP ?
Sorry if my question sounds confusing, as im quite confused with how MDIL works for the Enterprise store :)
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681686.aspx
The Microsoft recommended way is to use a PowerShell script BuildMDILXap.ps1 that ships with WP8 SDK. Given a XAP file and an enterprise code signing key (that you get from Symantec) -- it unzips the contents, runs the MDIL compilation, code signs the DLLs, zips them back to XAP and signs the XAP file as well.
The script uses two tools - MDILXAPCompile.exe and XapSignTool.exe to do the work. The phone is perfectly capable of running the IL (JIT). In my experience (a simple LOB app with not-too-complex UI showing data from server) there is no visible performance difference with and without the MDIL compilation. YMMV.
While MDIL compilation makes the assemblies bigger, complex apps might benefit from it. I would watch the startup performance and perhaps any heavy computations (if applicable).
After installing .NET 4.5 beta, I noticed that my calls to Assembly.LoadFrom with a network path succeed without explicitly specifying "loadFromRemoteSources=true" in the application configuration file (whereas with .NET 4.0 this used to result in "System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.")
I wonder if this, if it indeed is new behaviour and not something special in my setups (I've not yet decompiled the respective reflection classes or debugged the loading process to examine the differences), is an intentional change in policy and will remain in the RTM version?
The docs don't seem to indicate this change in behaviour. http://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx. And I would have expected a notice of it.
If it does work this way, then you're granting full trust by default and invisibly to a potentially dangerous assemblies and I can't imagine that would be the order of the day.
Have you got it added to machine.config per chance?
Also I would create a small program and target it to the 4.0 platform and induce this exception. Then I would retarget it to 4.5 and see if indeed it's true. Then I'd move the binaries to another machine and test there.
I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.