I am trying to release an iOs app, but when I build in release mode I get the following error
Severity Code Description Project File Line Suppression State
Error Can't resolve the reference 'System.Void ObjCRuntime.DisposableObject::Dispose()', referenced from the method 'System.Void Xamarin.Forms.Platform.iOS.ContextActionsCell::.cctor()' in 'Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. SoteriaTennant.iOS
I cannot determine what is causing this error above and how to solve it
I tried to set the linker behaviour to Don't link but then the app gets rejected for the following reason
Guideline 2.5.1 - Performance - Software Requirements
We noticed that your app uses HealthKit, but your app does not appear to include any primary features that require health or fitness data.
The intended use of HealthKit is generally to share health or fitness data with other apps or devices as a part of the app's core functionality.
Next Steps
To resolve this issue, please remove any HealthKit functionality from your app, as well as any references to this app’s interactivity with HealthKit from the app or its metadata. This includes removing any HealthKit-related keys in your app's Info.plist as well as removing any calls to HealthKit APIs, including those from 3rd party platforms, from your app.
Related
(If this question is poorly worded, could someone please help me clear it up?)
I have an Azure Function (2.0) which relies on some System.Drawing code. I've added a NuGet reference to System.Drawing.Common (4.5.0).
After publishing the app, however, when the function is called, it produces the error:
System.Private.CoreLib: Exception while executing function:
[MyFunctionName]. System.Drawing.Common: System.Drawing is not
supported on this platform.
As far as I'm aware, System.Drawing.Common is supported on .NET Core now, which I believe is the environment in which my Azure Function is running. The actual project is a .NET Standard 2.0 project, though.
I am confused as to how to resolve this. I've tried converting the project to a .NET Core 2.1 project but that led to bizarre errors related to "Metadata generation failed" and an inability to find System.Runtime.
My project references Microsoft.Azure.WebJobs.Extensions.EventGrid (2.0.0-beta2) if that's relevant.
It's not about the CLR, it's about the sandbox.
System.Drawing relies heavily on GDI/GDI+ to do its thing. Because of the somewhat risky nature of those APIs (large attack surface) they are restricted in the App Service sandbox.
Win32k.sys (User32/GDI32) Restrictions
For the sake of radical attack surface area reduction, the sandbox prevents almost all of the Win32k.sys APIs from being called, which practically means that most of User32/GDI32 system calls are blocked. For most applications this is not an issue since most Azure Web Apps do not require access to Windows UI functionality (they are web applications after all).
Try to find an different library that doesn't rely on System.Drawing/GDI, like ImageSharp.
A little update can help a lot of people.
Now you can switch your Azure Function to v3:
in Function app settings panel -> Runtime version ~3
With this setup, your code run in a sandbox that support Core 3, (you don't need to rebuild your dll to Core3, i run my .net core 2.1 dll without errors), and surprise... you don't get this exception anymore:
System.Drawing.Common: System.Drawing is not supported on this platform.
Because the CLI can found GDI/GDI+ that need in the subsystem.
Now i can convert html to pdf without go crazy.
It's possible to install Application Insights via the extensions section in Azure App Services, but it's also possible to just install the packages via NuGet and define the APPINSIGHTS_INSTRUMENTATIONKEY application setting. You can also do both.
What is the difference?
Edit:
I have found what the differences are between installing the extension or the NuGet packages:
You can configure monitoring by instrumenting the app in either of two ways:
Run-time - You can select a performance monitoring extension when your web app is already live. It isn't necessary to rebuild or re-install your app. You get a standard set of packages that monitor response times, success rates, exceptions, dependencies, and so on.
Build time - You can install a package in your app in development. This option is more versatile. In addition to the same standard packages, you can write code to customize the telemetry or to send your own telemetry. You can log specific activities or record events according to the semantics of your app domain.
Source: https://learn.microsoft.com/en-us/azure/application-insights/app-insights-azure-web-apps#run-time-or-build-time
But what if you do both? Will there be anything beneficial about it?
But what if you do both? Will there be anything beneficial about it?
The extension detects that your app has already brought Application Insights with it and won't do anything, except dropping a profiler, which helps collect full SQL Statement in Dependencies. Without the profiler full SQL Statement won't be collected but everything else should just work fine.
(If you are using 2.3.0 or earlier of SDK or if you application is targeting old .NET Framework like 4.0, then profiler does better correlation of dependencies as well.
In short, Starting with 2.4.0 of SDK, the only advantage of installing extension on top on nuget installation is to get full SQL Statements in Dependency Telemetry.
But what if you do both? Will there be anything beneficial about it?
As you know we could install the packages via NuGet to use Application Insights .For this way, we could add custom telemetry data in my code,and monitor the telemetry data in application insights tools in Visual Studio. This will be very convenient. You could also refer to this article to add custom telemetry data.
Code in MVC Porject:
public ActionResult Index()
{
Trace.TraceInformation("my trace info Home/Index");
var telemetry = new Microsoft.ApplicationInsights.TelemetryClient();
RequestTelemetry requestTelemetry = new RequestTelemetry();
telemetry.TrackTrace("Home/Index Main");
telemetry.TrackPageView("Home/Index");
return View();
}
The telemetry data in Application insight tool:
The application insights in App Service,you can only see limited data and trends in past 24 hours. This is very convenient for you to view the main telemetry data in the app service directly. But if you want to know more details, that is not a good choose.
The most comprehensive monitor data and services are in application insight service. You could click 'View more in application insights' in App Service monitor extension to go. Or you could go to application insight service directly.
Time Range in application insight service(include custom time range).
I am facing a strange problem with packaging an assembly for Azure worker role. I am building a sample Azure cloud application having one website and a worker role. I am referencing a third party assembly, myasm.dll in both website and worker role project. The myasm.dll has dependency on two other assemblies. When I build the project all three(myasm.dll and two dependent assemblies) third party assemblies are getting copied to bin directory for both website and worker role projects. So far so good.
When packaging is done for worker role, off the three third party assemblies, only two assemblies are included in the package, the third assembly is not included. Strangely enough, packaging of Website project includes all three assemblies. I created one more worker role to test the behavior but same behavior was seen again.
Is this a known issue or something? Any help is highly appreciated.
I use VS2012 Update 4.
Package will not include any dll which is not explicitly used in your project or referenced. I know this problem occurs when you do not use type explicitly in a your project(old bug raised - with won't fix status)
I guess your best option is to explicitly reference those missing dll's (see here) or try to add dummy usage of types from missing dependencies.
I have a fairly stable server application version that's been deployed for nearly a year at dozens of customers.
One new customer recently setup the application and is getting the following error:
System.MethodAccessException: Attempt by security transparent method
[SomeMethod] to access security critical method [SomeOtherMethod]
failed.
Both SomeMethod and SomeOtherMethod are methods in assemblies that I wrote, that are built against .NET 4, and that are running inside a Windows Service. If it makes a difference, SomeOtherMethod does reference a type from a 3rd party assembly (EntLib 4.1) built against .NET 2.0. Looking at the code for EntLib 4.1, I do see that they use both SecurityTransparent and APTC attributes, but this has never caused issues at other clients.
These assemblies were upgraded from the .NET 2.0 CLR, but a long time ago. This exact code is running on other customers just fine, and I'm not explicitly using the APTC attribute nor am I using the SecurityCritical attribute anywhere.
This leads me to the conclusion that it's a configuration issue or perhaps .NET Framework patch issue. Has there been a patch released for .NET that would cause this breaking change? Is there a configuration setting some where that enforces this type of check which is off by default but that my customer may have enabled?
One last point. My service utilizes SSRS RDLCs to generate PDFs. Due to some changes in .NET 4, I must force the service to use the legacy security policy via the following config:
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true" />
</runtime>
For more details on why I need to do this, see this stackoverflow post: Very High Memory Usage in .NET 4.0
The important point is that I do this at all my other customers as well. Only this one customer is having issues.
Sigh, the patterns and practices employed by the Microsoft Patterns And Practices team that's responsible for the Enterprise libraries are pretty deplorable. Well, the exception is accurate, you cannot call a method that's decorated as "I'll definitely check security" from code that's decorated with "Meh, I won't check security so don't bother burning the cpu cycles to check it". Which scales about as well as exception specifications as used in Java. CAS is incredibly useful, but diagnosing the exceptions is a major headache and often involves code that you don't own and can't fix. Big reason it got deprecated in .NET 4.
Editorial done. Taking a pot-shot at the problem, you need to find out why CAS is being enforced here. The simplest explanation for that is that the service doesn't run in full trust. The simplest explanation for that is that the client didn't install the service on the local hard drive. Or is generally running code in don't-trust-it mode even on local assemblies, a very paranoid admin could well prefer that. That needs to be configured with Caspol.exe, a tool whose command line options are as mysterious as CAS. Pot-shooting at the non-trusted location explanation, your client needs to run Caspol as shown in this blog post. Or just simply deploy the service locally so the default "I trust thee" applies.
Editing in the real reason as discovered by the OP: beware of the alternate data stream that gets added to a file when it is downloaded from an untrusted Internet or network location. The file will get a stream named "Zone.Identifier" that keeps track of where it came from with the "ZoneId" value. It is that value that overrides the trust derived from the storage location. Usually putting it in the Internet zone. Use Explorer, right-click the file and click "Unblock" to remove that stream. After you're sure you can trust the file :)
I was facing the similar issue while running the downloaded WCF sample from http://www.idesign.net/ while using their ServiceModelEx library.
I commented out the below line in AssemblyInfo.cs in ServiceModelEx project
//[assembly: AllowPartiallyTrustedCallers]
and it worked for me.
In case it helps others i post my solution for this issue:
1) On the AssemblyInfo.cs, removed/commented the [assembly: SecurityTransparent] line.
2) The Class and the Method that does the actual Job was marked as [SecuritySafeCritical], in my case establishing a Network Connection:
[SecuritySafeCritical]
public class NetworkConnection : IDisposable
{
[SecuritySafeCritical]
public NetworkConnection(string networkName, NetworkCredential credentials)
{
.............
}
}
3) The Caller Class and Method was market as [SecurityCritical]:
[SecurityCritical]
public class DBF_DAO : AbstractDAO
{
[SecurityCritical]
public bool DBF_EsAccesoExclusivo(string pTabla, ref ArrayList exepciones)
{
....
using (new NetworkConnection(DBF_PATH, readCredentials))
{
....
}
}
}
In my case it was an issue when I managed a NuGet packages in the solution some package overrides System.Web.Mvc assembly version binding in main web site project. Set back to 4.0.0.0 (I had 5.0 installed). I didn't change notice the change because Mvc v4.0 was installed and accessible via GAC. Set back
I am experimenting with ServiceStack's JSON engine. I grabbed the MonoTouch binary build, v2.20. Works fine from simulator, but from the iOS device (iPad2, iOS5) I get an exception thrown by the type initializer for JsonWriter (and not much other than that). I am using MonoTouch 5, MonoDevelop 2.8.1, and targeting iOS 5. I have disabled library linking because I am getting an error when enabled.
I created a sample and uploaded to https://github.com/t9mike/ServiceStack-JSON1.
I'm trying to determine whether the issue is my compilation options, Service Stack, or MonoTouch. Thanks in advance.
A quick partial answer that might help:
I have disabled library linking because I am getting an error when enabled.
The current (5.0) managed linker can eliminate some unused (from a static analysis point of view) code from your application. This generally occurs when using Link all option, i.e. where user code gets processed by the linker.
One alternative is using the Link SDK assemblies only that won't touch the user code (only the code shipped with MonoTouch itself will be processed by the linker).
Another alternative is adding [Preserve] attributes on your code to ensure the serializer requirements are still met after the linker has processed your code. More information about the linker and [Preserve] attributes can be found here.
The next (5.2) release of MonoTouch will include a bit more sophisticated step in the linker to ensure the basic XML serialization and DataContract requirements are not broken. Not sure if this will solve this specific case (ServiceStack JSON) but I'll have a look into it.
As for the rest of your question I'll try to build this myself and duplicate your issue.
I ended up grabbing the ServiceStack.Text sources from GitHub, version 3.0.3. I created a new MonoTouch library project. I had to tweak ServiceStack.Text/JsConfig.cs slightly to conditionalize away the System.Drawing.Color bits. I'll send a patch and MT csproj to the authors.
After using this new assembly, my sample MT app ran fine on the device. I have updated my sample at https://github.com/t9mike/ServiceStack-JSON1 with the new ServiceStack.Text dll.