We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

SetLicense() Object reference not set

I'm getting an error when trying to SetLicense. I noticed then when upgrading from 5.7.0.0 to 6.2.0.0. However, even after completely reverting everything to 5.7.0.0, we still see the same problem on our build server. Local unit tests do not run into this issue. There doesn't appear to be a difference that we can see when comparing our assemblies from a few weeks ago with today's code (using 5.7.0.0 for both).

{
...
"InnerException": {
"$type": "System.InvalidOperationException, mscorlib",
"ClassName": "System.InvalidOperationException",
"Message": "Failed to set license. Details: Object reference not set to an instance of an object",
"InnerException": null,
"HelpURL": null,
"StackTraceString": " at Aspose.Email.License.SetLicense (System.String licenseName) <0xf30d550 + 0x0011f> in :0 \n at kCura.Mail.AsposeLicenseManager.Initialize () <0xf30d4d0 + 0x0005b> in :0 \n
...
}

Thanks.

Hi Eric,

Thank you for contacting Aspose Support team.

Can you please create a simple console application with license placed along with it and then check if it still raises an exception on the server? Please make sure that to clear the Global Assembly Cache (GAC) so that you should be sure about the exact license path from where it is accessed.

Both of those were attempted but did not reveal any answer. The console app succeeds when initializing the license. What are some other paths I can go down that could be the cause of this problem?

Hi Eric,

We are not aware of any other such place where it needs to be checked. Can you please share your license file with us so that we can deploy it at our web server and check it for possible error as you have mentioned? You may please follow instructions in this link if you want to share your license file with us.

I’ve shared the license with you. Here’s some information about our build environment on OSX. Do you know of any situations where these versions cause problems with the licensing?


Target Framework: Mono / .NET 4.5

=== Xamarin Studio ===

Version 5.10.1 (build 6)

Installation UUID: f0969ed0-680d-46d0-b030-1d4dcf71a8e4

Runtime:

Mono 4.2.1 (explicit/6dd2d0d)

GTK+ 2.24.23 (Raleigh theme)

Package version: 402010102

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)

Build 6A2008a

=== Xamarin.Mac ===

Version: 2.4.0.109 (Business Edition)

=== Xamarin.iOS ===

Version: 9.4.0.0 (Starter Edition)

Hash: 7322991

Branch: master

Build date: 2015-12-08 16:20:29-0500

=== Build Information ===

Release ID: 510010006

Git revision: 0b60eecdb531933734519c13257d16a780274aab

Build date: 2015-12-04 20:28:20-05

Xamarin addins: 9876fd7c9837977178411ec7375b4352c0a0d6af

Build lane: monodevelop-lion-cycle6-baseline

=== Operating System ===

Mac OS X 10.10.5

Darwin pdx-mac-mini-03 14.5.0 Darwin Kernel Version 14.5.0

Tue Sep 1 21:23:09 PDT 2015

root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64

I have also tried to use the stream overload for setLicense(), but this did not work either. This is the stack trace:


{
“$type”: “System.InvalidOperationException, mscorlib”,
“ClassName”: “System.InvalidOperationException”,
“Message”: “Failed to set license. Details: Object reference not set to an instance of an object”,
“InnerException”: null,
“HelpURL”: null,
“StackTraceString”: " at Aspose.Email.License.SetLicense (System.IO.Stream stream) <0xefa26e8 + 0x0010f> in :0 \n at kCura.Mail.AsposeLicenseManager.Initialize () <0xefa2480 + 0x00153> in :0 \n at kCura.Collection.Plugin.Exchange.AsposeExchangeService.InitializeLicense () <0xefa2460 + 0x0000b> in :0 \n at kCura.Collection.Plugin.Exchange.ScoutProcessor.OnExecute (kCura.Collection.Plugin.Exchange.ExchangeConnectionInfo connectionInfo, IExchangeQueryCriteria dateCriteria) <0xefa2388 + 0x00019> in :0 \n at kCura.Collection.Plugin.Exchange.ScoutProcessor.Execute (kCura.Collection.Plugin.Client.Entities.ParameterValueEntityCollection parameters) <0xef9f0d0 + 0x0069b> in :0 ",
“RemoteStackTraceString”: null,
“RemoteStackIndex”: 0,
“HResult”: -2146233079,
“Source”: “Aspose.Email”,
“ExceptionMethod”: null,
“Data”: null
}

Hi Eric,

Please spare us a little time so that we can setup test environment for investigating the issue further. We’ll get back to you on this soon. We appreciate your patience in this regard.

That works, thank you. Is it possible to get a temporary license in the mean time to test on our end?


To be perfectly clear about the state we are in:
At a certain point in time, our app stopped working with Aspose, with the null reference exception listed above. We thought it was related to upgrading to 6.2.0.0, but it appears this problem happened before that time, because it still persists once downgrading to 5.7.0.0. This only happens on OSX, with the specific environment also detailed above. Steps we’ve taken so far:
  • Remove our CI from being involved with building the application at all - it still fails locally on OSX.
  • Compared the assemblies from a working application to a non working application - nothing notable found.
  • Reviewed the source changesets that happened during this window of time - nothing is related to the problem.
  • Overloaded the SetLicense() method with a stream instead of a file location - still has a null reference exception.
  • Used multiple OSX environments - all still have the same error.
-Erik

Hi Eric,

You can get a 30-day temporary license free of cost at step 4 of this process. We’ll keep your shared summary of the issue in consideration while testing the issue and will soon revert back to you on this.

Hi Eric,

We have tested this issue using the latest version of Aspose.Email for .NET on a Mac OS X and latest downloaded version of Xamarine Studio with Mono framework but were not able to face any issue with the license setting. Could you please share if the temporary license worked for you?

The temporary license did not resolve the issue. We’re looking into a potential issue with AppDomain as our next line of inquiry.

Hi Eric,

Thank you for sharing feedback. Please let us know when your inquiry is completed. We’ll look into your feedback for further assistance in this regard.

Hi Kashif,

I'm the senior tech lead for the team Erik is assigned and I'll be taking over. I designed all of our integration points with Aspose and we have had a completely working cross-platform solution for almost 14 months or so.

I'm 100% certain that this isn't a simple case of an improper API call, etc. Our architecture is such that all of the code in question is shared between 2 platforms and every bit of it is passing when executed from our automated tests. Furthermore, the Windows implementation works totally fine. I also don't believe this issue is purely due to the Mac/OSX environment either.

With that said, please let me know the following:
  • Does Aspose have any kind of internal logging that we might be able to hook into? If so, provide just enough details so we can take a look.
  • We want to identify any possible scenario, from your side, that the call to setup the license can throw that exception, regardless of whether a simple string is provided or stream.
    • We really need to understand, by looking at the source on your side, how this can occur. This may shed light on the underlying issue.
  • If you cannot possibly address either of these 2, could you possibly put together a "special" assembly that adds excessive logging entirely around the license initialization method, we'll run it, and provide you the results.
Thanks,
Scott

Hi Scott,

For your answers:

  • The API doesn’t have any such kind of internal logging that you can utilize for this purpose.
  • We have inquired about this from our Product team and no such issue or a test case is known to us where the call to setup the license can throw that exception. Could you please confirm if the access to license file is available and there are no permission limitations? Though in that case, it should throw some permission exception, we still want to know if you can read the file using normal I/O operations.
  • We have requested our Product team to share any such possibility and will update you here as soon as information is available.
  • Is it possible for you to create a Mac OS X VM and share that along with your sample project with us where the issue could be reproduced?

Hi Kashif,


As I expected, the solution to this problem wasn’t directly related to the API. Ultimately, the root cause was an AssemblyResolve event handler that fires during the SetLicense API method call. Under Windows, the “RequestingAssembly” is always non-null. This has always been true for .NET in OSX except when SetLicense is called.

It was pretty easy to see that a null reference occurred just before the Aspose exception is thrown with the “Failed to set license” message. I’m happy to report that the issue has been addressed and your product wasn’t at fault. I would say that it might not be a bad idea to consider the “AssemblyResolve” and “SetLicense” keywords together in a searchable KB.

I have bolded the code that was added to the event handler that resolved this problem.

Regards,
Scott

private Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
{
if (args.RequestingAssembly != null && !string.IsNullOrEmpty(args.RequestingAssembly.Location)) {}

Hi Scott,

We are glad to share that has been resolved and will further discuss with our Product team for possible inclusion for NULL reference checking.