I think I have felt into a trap. I had an idea to control GHI mainboard over CDC. It had to be a very practical solution. However, I have not realized (until now) that I won’t be able to use a device that is connected to COM1 while I am using CDC. That, of course, is not desirable.
My question is - can I get CDC running without enabling serial debugging on COM1?
P.S. I have a bad feeling that my chances of achieving this are very low. But maybe somebody can offer a “dirty hack” 
Using MF 4.2 on a windows 7/32 bit machine i was still using it. Since a few weeks i am on a win7/64 bit machine and it wont work anymore. I think it has more to do with the USB driver.
What do you mean? Are you saying that CDC is not working for you? It does work fine on Win7/64 and Win8/64. The problem I am having is that I do not want to enable serial debugging on COM1 while I am using CDC.
@ iamin - Since there is only one USB client port on a device, it can either be used for the USB debugger/communication or one of our devices. If you want to use CDC, you’ll have to use serial debugging.
What if I don’t need debugging? Let’s say I want CDC and XBee running on COM1 at the same time.
@ iamin - The USB debugger port is still created on startup and would conflict.
@ iamin - serial debugging also includes serial deployment. will you need to deploy programs?
I understand that. I was looking for a way to avoid this.
No. I deploy my program over USB, then I short MODE pin to ground with a switch and use USB port as CDC. After this I no longer need deployment or debugging capabilities, but I want COM1 
@ iamin - I do not think you can avoid it currently.
It looks it is possible to change the serial debugging port on Netduino devices. It can be either COM1 or COM2. More info: Switching deployment/debugging between USB and COM1/COM2 - Beta Firmware and Drivers - Netduino Forums
Unfortunately, MFDeploy that they provide does not work with GHI mainboards.
I took a quick look at what they have done. There are two classes that take care of setting this configuration: MFDeploymentTransportConfig and MFDeploymentTransportConfigDialog. At one point the following gets executed [em]this.m_cfg.Save();[/em] which I believe does all the magic.
public void Save()
{
this.m_cfgHelper.WriteConfig("SL_TRANSPORT_CONFIG", this.m_cfg);
}
public void WriteConfig(string configName, IHAL_CONFIG_BASE config)
{
this.WriteConfig(configName, config, true);
}
public void WriteConfig(string configName, IHAL_CONFIG_BASE config, bool updateConfigSector)
{
uint num = 0;
HAL_CONFIG_BLOCK configHeader = config.ConfigHeader;
num = (uint) sizeof(HAL_CONFIG_BLOCK);
configHeader.DriverNameString = configName;
configHeader.HeaderCRC = 0;
configHeader.DataCRC = 0;
configHeader.Size = ((uint) config.Size) - num;
configHeader.Signature = 0x324c4148;
config.ConfigHeader = configHeader;
byte[] rgBlock = this.MarshalData(config);
configHeader.DataCRC = CRC.ComputeCRC(rgBlock, (int) num, (int) configHeader.Size, 0);
config.ConfigHeader = configHeader;
rgBlock = this.MarshalData(config);
configHeader.HeaderCRC = CRC.ComputeCRC(rgBlock, 8, ((int) num) - 8, 1);
config.ConfigHeader = configHeader;
rgBlock = this.MarshalData(config);
this.WriteConfig(configName, rgBlock, true, updateConfigSector);
}
The last two methods are written by MS.
I am not an expert here. Maybe someone from the GHI team could take a look at this? Is it possible to change debugging port for GHI mainboards as well?
@ iamin - It is very likely possible to give the ability to change the COM port for serial debugging, it’s just a question of whether it’s worth the cost and it would help enough people.
This feature would definitely enhance the versatility of your mainboards.
It looks like to change COM port for serial debugging it requires modifying one entry within HAL_CONFIG_BLOCK. If that is the case, maybe it is not that hard to implement.
Anyway, I would like to see this option available 8)
@ iamin - You can always create a task tracker entry to gauge the interest of other users as well.