I'm having a hard time using the newest google analytics piece with the MonoTouch bindings that Miguel has here: https://github.com/migueldeicaza/monotouch-libs/tree/master/GoogleAnalytics
I'm guessing that the interface has changed a bit in ways that are incompatible, but I'm not sure how to diagnose. At run time, I get this error: System.InvalidCastException: Cannot cast from source type to destination type.
at GoogleAnalytics.GANTracker.get_SharedTracker () [0x00000] in :0
It appears that only two methods were added, so I attempted to add these to "api.cs" - but got a series of compiler errors that didn't seem to tie into the situation.
[Export ("setCustomVariableAtIndex:index:name:value:scope:error"),Internal]
bool _SetCustomVariableAtIndex(int index, string name, string value, int scope, IntPtr nsErrorPtr);
[Export ("setCustomVariableAtIndex:index:name:value:error"),Internal]
bool _SetCustomVariableAtIndex(int index, string name, string value, IntPtr nsErrorPtr);
Has anyone else overcome this, and is successfully using the NoThumb version of google analytics with MonoTouch ?
I had the same issue, but I got it to work eventually.
I had to use the btouch tool, on the latest version of Google Analytics for iOS. This recreated the GANTracker.dll.
I also added this to my project file under iPhone Build->Additional mtouch Args:
-v -v -v -gcc_flags "-L${ProjectDir}/Google -lGoogleAnalytics -lsqlite3.0 -force_load ${ProjectDir}/Google/libGoogleAnalytics.a"
I have a Google subfolder in my project with these files:
GANTracker.dll
GANTracker.h
libGoogleAnalytics.a
Sorry, I don't have more specific instructions on btouch, it's been a while.
Related
Main context
We're actually trying to get a multi-threading version of Ghostscript x64 DLL, to make use of it through Ghostscript .NET. This component is supposed to "allow runing multiple Ghostscript instances simultaneously within a single process", but, as we have checked in our project, works fine until concurrent requests are made to the application. Same behavior can be replicated lauching same method using Tasks. The error description that raises in both cases, just when a call to the process is made until the last is being executed, is:
An error occured when call to 'gsapi_new_instance' is made: -100
Even it does no seem to be related with .NET directly, I will post a sample of our C# method code, just for contextualize.
// Define switches...
string[] switchesArray = switches.ToArray();
using (GhostscriptProcessor procesador = new GhostscriptProcessor())
{
try
{
procesador.StartProcessing(switchesArray, null);
byte[] destinationFile = System.IO.File.ReadAllBytes(destinationPath);
return destinationFile;
}
catch (Exception ex)
{
throw ex;
}
finally
{
System.IO.File.Delete(sourceFile);
}
}
THREADSAFE solution
Starting our investigation, we found this KenS's answer on this post, indicating that Ghostscript DLL must be generated with GS_THREADSAFE compiler definition.
To clarify, as we make use of Ghostscript 9.52 x64 to generate our PDFs, we need this x64 DLL compiled for Release configuration. After trying to compile Ghostscript sources on Windows 10 x64 machine, using Visual Studio Community 2017 and Visual Studio Community 2019, we finally managed to build and generate all items (only with VS Community 2019) without GS_THREADSAFE parameter, just to confirm that compilation is fine, and we check that the DLLs and executables are working. For this process we took in mind all we found in Ghostscript official documentation.
As we have no other guide to include this GS_THREADSAFE parameter, we followed the instructions given in this solution, including XCFLAGS="-DGS_THREADSAFE=1" on nmake build commands, usign this sentence for Rebuild all option:
cd .. && nmake -f psi\msvc32.mak WIN64= SBR=1 DEVSTUDIO= XCFLAGS=-DGS_THREADSAFE=1 && nmake -f psi\msvc32.mak WIN64= DEVSTUDIO= XCFLAGS=-DGS_THREADSAFE=1 bsc
This approach, rises an error during build:
Error LNK2019 unresolved external symbol errprintf_nomem referenced in
function gs_log_error File \mkromfs.obj 1
As it seems, the file mkromfs.c has a method called errprintf_nomem, which can't be found when GS_THREADSAFE is set.
Questions
1 - Is there any public release of Ghostscript that include x64 DLLs compiled to be THREADSAFE?
And, if not (that's what I'm guessing...)
2 - Is it possible to get this DLL to be THREADSAFE without changing the source code?
3- Could anyone provide, please, a step by step guide or walkthrough to build a x64 Ghostscript DLL using GS_THREADSAFE using Visual Studio (or even any other possible alternative) over Windows 10 x64?
4 - A few posts talk about people achive to manage multithreading using Ghostscript .NET. I assume this examples are all using a GS_THREADSAFE DLL... Is any other workaround we have passed?
Thank a lot in advance.
To summarize all this questions, and as a guide for future developers having this same trouble, these are the answers we've found until now:
AS #KenS mentions in his reply: "No, the Ghostscript developers don't actually build thread-safe versions of the binaries."
At this very moment, clearly not, as it has been reported on this opened bug.
As it seems to be a matter of commercial licensing support, we avoid comment on this point anymore.
Thanks again to #HABJAN. I absolutely take back what I've stated on my question, as it is possible to have Ghostscript .NET working on multi-threading scenarios. Below comes the solution we applied, in case it could be useful for someone.
Based on HABJAN example, what we have done to achieve this was to create a custom class to capture Ghostscript logging:
protected class ConsoleStdIO : Ghostscript.NET.GhostscriptStdIO
{
public ConsoleStdIO(bool handleStdIn, bool handleStdOut, bool handleStdErr) : base(handleStdIn, handleStdOut, handleStdErr)
{
}
public override void StdIn(out string input, int count)
{
char[] userInput = new char[count];
Console.In.ReadBlock(userInput, 0, count);
input = new string(userInput);
}
public override void StdOut(string output)
{
//log
}
public override void StdError(string error)
{
//log
}
}
For our previous method, we simple include a call to this class and this avoids errors when multiple tasks are executed at the same time:
// Define switches...
string[] switchesArray = switches.ToArray();
using (GhostscriptProcessor procesador = new GhostscriptProcessor())
{
try
{
procesador.StartProcessing(switchesArray, new ConsoleStdIO(true, true, true));
byte[] destinationFile = System.IO.File.ReadAllBytes(destinationPath);
return destinationFile;
}
catch (Exception ex)
{
throw ex;
}
finally
{
System.IO.File.Delete(sourceFile);
}
}
Well, it seems to me that you are asking here for technical support.
You clearly want to use Ghostscript in a commercial undertaking, indeed one might reasonably say you want an enterprise version of Ghostscript. Presumably you don't want to alter the source in order to permit you to use an open source license, because you don't want to pay for a commercial license.
With that in mind the answers to your questions are:
No, the Ghostscript developers don't actually build thread-safe versions of the binaries.
Currently, no. That's probably an oversight.
That would be a technical support question, there's no guarantee of technical support to free users, it's the one of the few areas of leverage for dual license vendors to persuade people to take up a commercial license. So I hope you will understand that I'm not going to provide that.
as far as I can see, no.
I have a Xamarin.iOS project and recently upgraded that plus my PCL project to have Windows Azure Mobile Services SDK 1.3.1.
However I now get an error when it tries to create a new MobileServiceClient.
{System.NullReferenceException: Object reference not set to an instance an object
at Microsoft.WindowsAzure.MobileServices.MobileServiceHttpClient.GetUserAgentHeader () [0x0002e] in d:\jw\ZumoSDKBuild_Dev\source\sdk\Managed\src\Microsoft.WindowsAzure.MobileServices\Http\MobileServiceHttpClient.cs:683
at Microsoft.WindowsAzure.MobileServices.MobileServiceHttpClient..ctor (IEnumerable`1 handlers, System.Uri applicationUri, System.String installationId, System.String applicationKey) [0x0004e] in d:\jw\ZumoSDKBuild_Dev\source\sdk\Managed\src\Microsoft.WindowsAzure.MobileServices\Http\MobileServiceHttpClient.cs:138
at Microsoft.WindowsAzure.MobileServices.MobileServiceClient..ctor (System.Uri applicationUri, System.String applicationKey, System.Net.Http.HttpMessageHandler[] handlers) [0x00040] in d:\jw\ZumoSDKBuild_Dev\source\sdk\Managed\src\Microsoft.WindowsAzure.MobileServices\MobileServiceClient.cs:199
at Microsoft.WindowsAzure.MobileServices.MobileServiceClient..ctor (System.Uri applicationUri, System.String applicationKey) [0x00000] in d:\jw\ZumoSDKBuild_Dev\source\sdk\Managed\src\Microsoft.WindowsAzure.MobileServices\MobileServiceClient.cs:150
at Microsoft.WindowsAzure.MobileServices.MobileServiceClient..ctor (System.String applicationUrl, System.String applicationKey) [0x00000] in d:\jw\ZumoSDKBuild_Dev\source\sdk\Managed\src\Microsoft.WindowsAzure.MobileServices\MobileServiceClient.cs:135
at MyApp.App..ctor () [0x00009] in c:\Users\adam\Documents\Visual Studio 2013\Projects\MyApp\App.cs:30 }
Looking at the source code of the MobileServiceClient here is the function it is failing on
private string GetUserAgentHeader()
678 {
679 AssemblyFileVersionAttribute fileVersionAttribute = typeof(MobileServiceClient).GetTypeInfo().Assembly
680 .GetCustomAttributes(typeof(AssemblyFileVersionAttribute))
681 .Cast<AssemblyFileVersionAttribute>()
682 .FirstOrDefault();
683 string fileVersion = fileVersionAttribute.Version;
684 string sdkVersion = string.Join(".", fileVersion.Split('.').Take(2)); // Get just the major and minor versions
685
686 IPlatformInformation platformInformation = Platform.Instance.PlatformInformation;
687 return string.Format(
688 CultureInfo.InvariantCulture,
689 "ZUMO/{0} (lang={1}; os={2}; os_version={3}; arch={4}; version={5})",
690 sdkVersion,
691 "Managed",
692 platformInformation.OperatingSystemName,
693 platformInformation.OperatingSystemVersion,
694 platformInformation.OperatingSystemArchitecture,
695 fileVersion);
696 }
I have no idea on what is specifically causing the error. Any help appreciated.
Update
If I run the following code, just in my app before I try to initialize the MobileServiceClient
AssemblyFileVersionAttribute fileVersionAttribute = typeof(MobileServiceClient).GetTypeInfo().Assembly
.GetCustomAttributes(typeof(AssemblyFileVersionAttribute))
.Cast<AssemblyFileVersionAttribute>()
.FirstOrDefault();
string fileVersion = fileVersionAttribute.Version;
With Don't Link it works perfectly. If I run it with Link SDK or Link All then assembly is equal to null.
Where to go from here I am not sure yet.
The intent of linking is to reduce overall app size by excluding unused namespaces, classes, and members. Linking most apps will require a manual iterative process of:
Enable full linking for whatever build config you're concerned with.
Clean and build the app.
Run the app, and observe what runtime exceptions occur as a result of missing types and methods (including constructors).
Add rules either to your mtouch command arguments or the link description XML file in order to skip linking on the namespaces, types, and classes that you find are throwing exceptions.
In order to link an app that uses the Azure Mobile Services Client PCL, you follow the same iterative process I just stated.
I prefer the XML-based config file strategy of linking preservation:
https://developer.xamarin.com/guides/cross-platform/advanced/custom_linking/
The XML file is commonly known as a link definition file. It allows you to control the linker in a declarative fashion, without adding [Preserve] attributes everywhere in your code; and for third-party libraries, without muddying up the mtouch arguments of Xamarin.iOS projects or the csproj file of Xamarin.Android projects. It can be named whatever you want, as long as you properly tell your platform project about it.
An appropriate configuration could look like this:
<?xml version="1.0" encoding="UTF-8" ?>
<linker>
<assembly fullname="Microsoft.WindowsAzure.Mobile">
<type fullname="Microsoft*" />
</assembly>
<assembly fullname="Microsoft.WindowsAzure.Mobile.Ext">
<type fullname="Microsoft*" />
</assembly>
</linker>
In each assembly node, you describe the types or members you want to preserve. For the sake of simplicity here, I've used a wildcard to include all types that begin with "Microsoft". That's matched by fully qualified name, including namespace.
However, as stated, you will encounter a runtime problem with the GetUserAgentHeader() method in the MobileServiceHttpClient class:
Fortunately, the source code is available. So, I pulled down the source and referenced it in my project. The exception occurs on line 699, where the the Version property of the fileVersionAttribute var is attempted to be retrieved. But fileVersionAttribute is null!...when linked. The LINQ statement that begins on line 695 returns null when linking is enabled. It does return a valid value when not linked; a value of "1.0.0.0".
WHY? I'm not quite sure yet. But that's the root cause of the exception.
Anyway, for now I'll have to include the Azure Mobile Service source in my project, and artificially set that value to "1.0.0.0"...which is dirty, and I'm not happy about it.
string fileVersion = fileVersionAttribute?.Version ?? "1.0.0.0";
EDIT:
Issue raised on github: https://github.com/Azure/azure-mobile-services/issues/855
I have finally discovered a way to prevent the linking of the Azure Mobile Services library, without disabling linking for everything else.
You can add
--linkskip=Microsoft.WindowsAzure.Mobile --linkskip=Microsoft.WindowsAzure.Mobile.Ext
to Additional mtouch arguments in the iOS build options under project settings for the iOS project.
This will skip the linker for the azure assemblies, but not the rest. More on the linker can be found at http://developer.xamarin.com/guides/ios/advanced_topics/linker/#Skipping_Assemblies
I needed to add
CurrentPlatform.Init();
in the AppDelegate in FinishedLaunching
Secondly in the iOS project I needed to go to
Properties > iOS Build > Linker Behavior and set it to "Don't link"
I still don't consider this the answer, its just a poor work around at the moment.
With a skeleton project with FirstView from HotTuna package, and with Build linker behavior set to "Link all assemblies", I get the following error:
System.MissingMethodException: Default constructor not found for type Cirrious.CrossCore.IoC.MvxPropertyInjector
Using NuGet package v3.1.1 for all MvvmCross (4 packages)
LinkerPleaseInclude file does have the line
[MonoTouch.Foundation.Preserve(AllMembers = true)]
Using the latest stable build:
On PC:
Xamarin for VS 1.12.278
Xamarin.iOS 1.12.278
Mac:
Xamarin.iOS 7.2.2.2
Of course with Linker behavior of SDK only, it runs fine. Any suggestions anyone?
Solved; So, with the basic project, there were three consecutive errors in the following order:
System.MissingMethodException: Default constructor not found for type Cirrious.CrossCore.IoC.MvxPropertyInjector
can be resolved either by --linkskip=Cirrious.Core (ugly), or by including the following in LinkerPleaseInclude.cs
public void Include(MvxPropertyInjector injector){
injector = new MvxPropertyInjector ();
}
Next error is:
Cirrious.CrossCore.Exceptions.MvxException: Failed to construct and initialize ViewModel for type {0} from locator MvxDefaultViewModelLocator - check MvxTrace for more information
This one is difficult; Simple fix is to ofcourse to do a --linkskip=portableLibrary, or to crate an instance of the ViewModel somewhere (perhaps in LinkerPleaseInclude.cs); problem with the second approach at-least in my case is, most of my VM doesn't have a parameter less constructor, and obviously using IOC in this case wouldn't help.
Final Error:
System.ArgumentNullException: missing source event info in MvxWeakEventSubscription
Parameter name: sourceEventInfo
Either use --linkskip=System (ugly), or add the following to LinkerPleaseInclude.cs
public void Include(INotifyPropertyChanged changed)
{
changed.PropertyChanged += (sender, e) => {
var test = e.PropertyName;
};
}
This was enough for my basic project to run with LinkAllAssemblies, Using LLVM optimizer, and Use SGen collector.
Hope this will help anyone looking for a solution.
I hit this when my XCode was out of sync with the latest Xamarin on my Mac. Upgrading XCode to the latest resolved the problem.
I am running my application in VS2012 and I am getting a runtime error;
When I look in the "Original Location" I see mscorlib.dll, but not mscorlib.pdb.
Why is this happening and how do I fix it?
Goto Tools, Options, Debugging, General, Enable Just My Code
This will prevent the debugger from trying to launch on a Internal .NET Framework Assembly.
Goto Tools, Options, Debugging, Symbols and set a cache location. Then hit load in the above and it will fetch the necesary symbols for you and store them in the cache location you provide.
Microsoft's compiler tools create symbols in separate files with a .pdb extension (program database). This allows them to create detached symbols for release binaries. With a symbol server, your IDE can fetch the symbol file matching the specific version of the DLL during debugging. You can configure this system for your own product binaries as well which can be very useful for post-mortem debugging any crashes on end-user machines.
See Microsoft's documentation for more details about using their public symbols.
I had this issue when I was using a static variable, whose value is assigned off a static method.
So, whenever I ran the application, this line of code threw exception. If you place a debug point on this (like I did), you will notice the exception being thrown.
The best Solution to solve this error is:
1: Open App.config file.
2: Paste this useLegacyV2RuntimeActivationPolicy="true" code in the startup tag.
3: Save it.
Now the error would disappear.
Moreover see Image. I have done this for you.
This happened to me for a different reason: I had referenced an old version of NLog (2.0) and needed to reference version 4.0, instead.
In a VB console app, in my case it was none of the above.
Just doing a string calculation in the Dim declarations before my subs.
The offending code:
Dim FylPrefix$ = Fyl.Substring(0, Fyl.LastIndexOf("."))
Moving this calculation into the sub it was needed in fixed it! GERONIMO!!
This can happen when you initialize a variable in your class declarations and that initialization throws an exception:
class Program
{
static OracleConnection ora = getOracleConnection();
}
static void main(string[] args)
{
ora.Open();
}
static OracleConnection getOracleConnection()
{
OracleConnection orax = new OracleConnection(description=(host=myHost)
(port=1521)(protocol=tcp))(connect_data=(sid=mySid)));user id=user;password=pw;
}
If an exception is thrown by getOracleConnection() you can get this error. Move your assignment (but not necessarily your declaration) inside of main (where it belongs anyway), and you will get the actual exception that is causing the error instead of the mscorlib error.
In my case the exception began to appear after I changed the "Assembly name" in the "Application" tab of the properties window. If that's the case with you try reverting to the original name and see if the exception disappears.
Perhaps the reason for this was that the new name did not match the AssemblyTitle in AssemblyInfo.cs.
if you have this type of project runtime error in visualstudio
Answer:Cntr+Alt+E open Exception window Uncheck All chechboxes
Must and shoud its working written by B sriram Mca Giet College
rajahmundry, east godavary ,2014 batch
I'm trying to port a new versio of the Isis2 library from .NET on Windows to Mono/Linux. This new code uses MemoryMappedFile objects, and I suddenly am running into issues with the Mono.Posix.Helper library. I believe that my issues would vanish if I could successfully compile and run the following test program:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO.MemoryMappedFiles;
namespace foobar
{
class Program
{
static int CAPACITY = 100000;
static void Main(string[] args)
{
MemoryMappedFile mmf = MemoryMappedFile.CreateNew("test", CAPACITY);
MemoryMappedViewAccessor mva = mmf.CreateViewAccessor();
for (int n = 0; n < CAPACITY; n++)
{
byte b = (byte)(n & 0xFF);
mva.Write<byte>(n, ref b);
}
}
}
}
... at present, when I try to compile this on Mono I get a bewildering set of linker errors: it seems unable to find libMonoPosixHelper.so, although my LD_LIBRARY_PATH includes the directory containing that file, and then if I manage to get past that stage, I get "System.NotImplementedException: The requested feature is not implemented." at runtime. Yet I've looked at the Mono implementation of the CreateNew method; it seems fully implemented, and the same is true for the CreateViewAccessor method. Thus I have a sense that something is going badly wrong when linking to the Mono libraries.
Does anyone have experience with MemoryMappedFile objects under Mono? I see quite a few questions about this kind of issue here and on other sites, but all seem to be old threads...
OK, I figured at least part of this out by inspection of the Mono code implementing this API. In fact they implemented CreateNew in a way that departs pretty drastically from the .NET API, causing these methods to behave very differently from what you would expect.
For CreateNew, they actually require that the file name you specify be the name of an existing Linux file of size at least as large as the capacity you specify, and also do some other checks for access permissions (of course), exclusive access (which is at odds with sharing...) and to make sure the capacity you requested is > 0. So if you had the file previously open, or someone else does, this will fail -- in contrast to .NET, where you explicitly use memory-mapped files for sharing.
In contrast, CreateOrOpen appears to be "more or less" correctly implemented; switching to this version seems to solve the problem. To get the effect of CreateNew, do a Delete first, wrapping it in a try/catch to catch IOException if the file doesn't exist. Then use File.WriteAllBytes to create a file with your desired content. Then call CreateOrOpen. Now this sounds dumb, but it works. Obviously you can't guarantee atomicity this way (three operations rather than one), but at least you get the desired functionality.
I can live with these restrictions as it works out, but they may surprise others, and are totally different from the .NET API definition for MemoryMappedFile.
As for my linking issues, as far as I can tell there is a situation in which Mono doesn't use the LD_LIBRARY_PATH you specify correctly and hence can't find the .so file or .dll file you used. I'll post more on this if I can precisely pin down the circumstances -- on this one, I've worked around the issue by statically linking to the library.