TFS Addin for Monodevelop – error adding repository

Found strange issue when trying to add new repository using TFS Addin in Monodevelop (ver 4.0.3.4) on my Mac.

After I setup repository and click button to add – get this error:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Xml.XmlException: Document element did not appear. Line 1, position 1. at Mono.Xml2.XmlTextReader.Read () [0x00000] in <filename unknown>:0 at System.Xml.XmlTextReader.Read () [0x00000] in <filename unknown>:0 at System.Xml.XmlReader.MoveToContent () [0x00000] in <filename unknown>:0 at MonoDevelop.Core.Serialization.XmlConfigurationReader.Read (System.Xml.XmlReader reader) [0x0000d] in /Users/builder/data/lanes/monodevelop-mac-monodevelop-3.0.3-branch/43da787a/source/monodevelop/main/src/core/ MonoDevelop.Core/MonoDevelop.Core.Serialization/XmlDataSerializer.cs:238 at MonoDevelop.Core.Serialization.XmlDataSerializer.Deserialize (System.Xml.XmlReader reader, System.Type type) [0x00000] in /Users/builder/data/lanes/monodevelop-mac-monodevelop-3.0.3-branch/43da787a/source/monodevelop/main/src/core/MonoDevelop.Core/MonoDevelop.Core.Serialization/XmlDataSerializer.cs:102 at MonoDevelop.VersionControl.VersionControlService.GetConfiguration () [0x00034] in /Users/builder/data/lanes/monodevelop-mac-monodevelop-3.0.3-branch/43da787a/source/monodevelop/main/src/addins/VersionControl/ MonoDevelop.VersionControl/MonoDevelop.VersionControl/VersionControlService.cs:597 at MonoDevelop.VersionControl.VersionControlService.AddRepository (MonoDevelop.VersionControl.Repository repo) [0x00000] in /Users/builder/data/lanes/monodevelop-mac-monodevelop-3.0.3-branch/43da787a/source/monodevelop/main/src/addins/VersionControl/ MonoDevelop.VersionControl/MonoDevelop.VersionControl/VersionControlService.cs:577 at TeamAddins.VersionControl.TFS.GUI.RepositoryMenu.AddRepositoryHandler (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 — End of inner exception stack trace — at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0 at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0 at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <filename unknown>:0 at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0 at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0 at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x00000] in <filename unknown>:0

 

Solution is easy – you should open the directory: /Users/<Your Login>/Library/Preferences/MonoDevelop-3.0 and look into the file ‘VersionControl.config’. In my case it was empty. This means – corrupted. Just delete it and Monodevelop will recreate it. This will be fixed as bug in future releases.

Predictable memory disposing in Monotouch

I have tasks:

– do huge memory block allocation in iOS (using Monotouch) application (like list with ~20Mb strings);

– clear list and have predictable memory disposing (using Garbage Collector, it should do this in time, or when we need more mem or etc).

This tasks was born from another big task. I should open huge txt files using QLPreviewController. But all I can see – memory was allocating and never disposing (but this story not about it, this leak Xamarin planning to fix it in 5.3.5 or 5.3.6 release – will wait ).

To check this allocations I used XCode -> Instruments -> Activity Monitor (btw very useful tool – highly recommended!)

My tests :

1. Alloc 20Mb -> check it in Activity Monitor (+20Mb)-> Dispose variable -> Wait and do something with app (alloc more, add, delete items) -> Check -> nothing changes – 20Mb still.

2. Alloc 10*20 Mb items-> Check – my app has almost the memory (if i will try to get more ~10-20Mb  – iOS will close my app) -> Dispose 5 items (~100Mb) -> Waiting (thinking about GC) + do something (thinking about GC again) -> Check  – nothing – ~200Mb

3. The same with 2, but start use GC.Collect (GC.MaxGeneration, GCCollectionMode.Forced); after disposing – Waiting (thinking about GC) + do something (thinking about GC again) -> Check  – nothing – ~200Mb

4. …

…

n. Wow! -> The same with 3, but after allocation I add GC. AddMemoryPressure (size); and after disposing GC. RemoveMemoryPressure (size); -> Activity monitor shows me that I have memory cleared and available for future allocations.

I can be wrong somewhere and please let me know my mistakes.

Hacking .Net

Great video about hacking .Net applications: http://vimeo.com/43536532

More details here: http://www.digitalbodyguard.com