Here’s a list of good MonoTouch related resources for getting started with C# development for the iPhone.
MonoTouch.info – Good collection of resources
Documentation
MonoTouch
iPhone OS Reference Library
Mono Documentation
MonoTouch Rosetta Stone
Blogs
Mike's Dev Blog
CodeSnack
Alex York .NET
martin bowling.com
Simon says
Sabon Rai Software
Kevin Sheffield
conceptdevelopment.net
Spinning the Web
Ruben’s Dev Blog
Tutorials
Here’s a list of good MonoTouch related resources for getting started with C# development for the iPhone.
MonoTouch.info – Good collection of resources
Documentation
Blogs
This works with both 32bit and 64bit versions.
The gist is that Vista and Windows 7 don’t recognize the remote when plugged into the usb port. Although after upgrading the MX-980 editor via Live Update there is a Vista driver under the program’s usb directory you need to assign the device in Device Manager to “Microsoft USB Sync” instead.
1. Install Mobile Device Center 6.1
2. Use Device Manage (after waking up the remote) to update it’s driver to “Microsoft USB Sync”.
For a more complete write-up see Get your URC MX-3000 to work on Windows Vista!
Sun’s Virtualbox supports VMWare VMDK files (virtual hard drives) however when booting from a vmdk file a couple of things must usually be done to prevent the virtual machine from hanging when booting up.
1. Booting in safe mode will reveal that the system hangs at the c:\system32\drivers\agp440.sys file. There are a variety of ways around this but the simplest (yet not the cleanest) way is to boot in recovery mode (or from another VM with the vmdk mounted as a second drive) and delete the agp440.sys file.
2. After rebooting with the vmdk file the system will likely hang at the Mup.sys file. This is a simple fix, in the VM’s System settings make sure the “Enable IO APIC” checkbox is checked.
For a more detailed explanation with other migration tips please see Vmware to Virtualbox Migration Issues.
My Vista IIS 7 box recently stopped listening on the localhost ip addresses for no apparent reason. I don’t know how this happened but I eventually found the solution.
I ran across the following command line that lists all the ip addresses that IIS is listening on (but I'm not sure how this differs from the IIS web site bindings):
netsh http show iplisten
This showed one ip address, which was my machine's ip address.
I ran this command on another vista pc that was working and it returned an empty list.
I then ran the following command line to remove the rouge ip address from the list:
netsh http delete iplisten ipaddress=192.1.1.123
Once I removed the ip address so the list was empty (which is what I have on another vista machine for comparison), localhost started working again.
FYI: This also applied to .NET WCF endpoints.
I believe the httpcfg command can do the same in older Windows OS versions.
Although there is a relative Reference HintPath in the .csproj file, when you move a solution to a different machine, the hint path may not be correct for that machine. An easy way to get around this problem is to just ensure that your needed assembly is in the Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies. Of course this should really only be done when you don't make any changes to the referenced assembly, such as a 3rd party dll.
A good summary: http://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx
From: http://msdn2.microsoft.com/en-us/library/8y13ka7c(VS.80).aspx
When the project system finds an assembly reference, it resolves the reference by looking in the following locations, in the following order:
1. The project directory. The project directory files appear in Solution Explorer
when Show All Files is not in effect.
2. Directories specified in this dialog box.
3. Directories displaying files in the Add Reference Dialog Box.
4. The project's obj directory. (Any assemblies created as a result of adding a COM
reference to your project are added to the project's obj directory.)
From: http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx
To display an assembly in the Add Reference dialog box
* Move or copy the assembly to one of the following locations:
o The current project directory (you can find these assemblies using the Browse tab).
o Other project directories within the same solution (you can find these assemblies using the Projects tab).
o The Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).
* Set a reference path to the directory containing the assembly using the Reference
Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#,
J#).
* Set a registry key that specifies the location of assemblies to display (This works
with MSBUILD):
Add one of the following registry keys, where <AssemblyLocation> is the directory of the assemblies that you want to appear in the Add Reference dialog box, for example, C:\MyAssemblies\.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
Basically the AssemblyFoldersEx key can have lots of subkeys. The subkeys can have any name.
I seem to forget the ASP.NET tracing page name occasionally, so here it is if I forget again:
trace.axd
Here's more detailed information: ASP.NET Tracing Overview
Wondering how the different .NET versions really fit together? Scott Hanselman gives a good rundown in his How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0 article.
Reading and Writing unicode strings to and from a Unicode Oracle database can be seem tricky and there isn't much information available on the subject. The solution is actually fairly simple, just make sure you are using the proper connection string.
ADO.NET: This is simple, using the OracleClient ensure that the connection string has: Unicode=true
Example: Data Source=ds;User ID=username;Password=pass1;Unicode=true;
ADO (VB6): In short the only 100% compatible solution is to use the ADO OraOleDB.Oracle data provider.
Example: Provider=ORAOLEDB.ORACLE;Data Source=ds;User Id=username;Password=password;
It also seems that the East Asian language files must be installed when writing those characters (at least with ADO). This is done from the Regional and Language Option control panel, Languages tab.
When using parameters (at least with ADO) if not using a DSN connection (which you can't really if using unicode), the appropriate parameter properties must be set manually (such as size), otherwise the following error occurs: Run-time error '-2147217839 (80040e51) Provider cannot derive parameter information and SetParameterInfo has not been called.
The grid below shows my test results from a VB6 application using ADO.
Actual 2 Japanese chars written: "とら" which has unicode values of 12392 and 12425.
Oracle 10g AL32UTF8 database.
write method vb shows in
read read char 1 readchar 2
actual value stored
debug
window length unicode value unicode value
in the database
MSDAORA: Provider=msdaora;Data Source=ds;User Id=username;Password=password;
FROM SQL: ‚Æ‚ç
2 12392
12425 ‚Æ‚ç
(4 characters)
FROM PARARMS: ‚Æ‚ç
2 12392
12425 ‚Æ‚ç
(4 characters)
PRESAVED: ¿¿
2 -129
-129
とら
Conclusion: Reads and writes
each encoded byte as separate characters, so the database ends up storing 4 characters
in this case instead of 2. Reading is consistent with writing so the resulting
read value is actually correct in memory, but the stored database value is incorrectly
stored. Reading a properly stored unicode string from the database results in
a corrupt read value.
DSN (Force SQL_WCHAR Support checked): dsn=dsnname;uid=username;pwd=password
FROM SQL: ??
2 191
191
¿¿
FROM PARARMS: ‚Æ‚ç
2 12392
12425 とら
PRESAVED: ‚Æ‚ç
2 12392
12425 とら
Conclusion: When writing unicode
strings using normal sql the stored value is corrupt, however using parameters when
writing results in a properly stored value. Reading a properly stored unicode string
from the database is successfull.
DSN (no workarounds checked): dsn=dsnname;uid=username;pwd=password
FROM SQL: ¿¿
2 -129
-129
¿¿
FROM PARARMS: ¿¿
2 -129
-129
とら
PRESAVED: ¿¿
2 -129
-129
とら
Conclusion: When writing unicode
strings using normal sql the stored value is corrupt, however using parameters when
writing results in a properly stored value. Reading a properly stored unicode string
from the database is NOT successful.
ORAOLEDB.ORACLE: Provider=ORAOLEDB.ORACLE;Data Source=ds;User
Id=username;Password=password;
FROM SQL: ‚Æ‚ç
2 12392
12425 とら
FROM PARARMS: ‚Æ‚ç
2 12392
12425 とら
PRESAVED: ‚Æ‚ç
2 12392
12425 とら
Conclusion: This works
in all situations.
The PRESAVED lines above indicate a record was previously saved to the database with a valid unicode value and was then read using the indicated data provider.