The compilation step missing from all .vcproj files when using VS2005-SP1

[GoogleCodeExporter]

Hi Arsen,

From the onset, let's clarify that this is most likely a Visual Studio 
problem, and not related to UniMRCP per se. And it is a problem that we 
approached in the past.

Apparently, VS2005-SP1 does not recognize the .c extension for the C 
source files, and therefore is incapable to associate the C compiler tool 
with this extension. This is visible to me by opening the "Property Pages" 
of any project and noticing that there is no C/C++ property under 
the "Configuration Properties" (see Figure 1 in the attached Word document 
containing various screenshots). Therefore, an attempt to "build solution" 
goes through all projects without doing anything. As an example, Figure 1 
mentioned above shows what happens when trying to build the 
project “aprtoolkit”.

To remedy this behavior, a pretty tedious action needs to be carried out: 

1. Select all the .c files in the solution and only the .c files, right 
click on the selection to bring up the “Property Pages”, select “All 
Configurations” in the “Configuration” drop-down list and do the 
following 
two steps.
2. Delete “Performing Custom Build Step” from “Configuration 
Properties”-
“Custom Build Step”-“General”-“Description”.
3. Replace the “Custom Build Tool” by the “C/C++ Compiler Tool” in 
the “Configuration Properties”-“General”-“Tool” sub-property (see 
Figure 
3).

I verified that this is a Visual Studio issue by creating an empty project 
and then adding a few arbitrary .c files to that project. The project is 
not compiled and shows exactly the same deficiency which can be remedied 
as described.

There is a significant difference between a .vcproj file created by VS2005-
base and one created by VS2005-SP1. In the former case, the “tools” are 
specified at the beginning of the file followed by an enumeration of the 
source files.

Example:

        <Filter
            Name="src"
            Filter="cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx"
            >
            <File
                RelativePath=".\src\apt_consumer_task.c"
                >
            </File>

etc...

In the latter case, the compilation tool is specified for every single 
source file.

Example:

        <Filter
            Name="src"
            Filter="cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx"
            <File
                RelativePath=".\src\apt_consumer_task.c"
                >
                <FileConfiguration
                    Name="Debug|Win32"
                    >
                    <Tool
                        Name="VCCLCompilerTool"
                    />
                </FileConfiguration>
                <FileConfiguration
                    Name="Release|Win32"
                    >
                    <Tool
                        Name="VCCLCompilerTool"
                    />
                </FileConfiguration>
            </File>

etc...

You certainly remember this issue from OpenMRCP. But interestingly, I 
found three or four source files in the Sofia-SIP package which suffered 
the same shortcoming (“Custom Build Tool” instead of “C/C++ Compiler 
Tool”).

I see three options:

1. Either I call Microsoft support and ask for an explanation/solution for 
this behavior.

2. Or you check-in and use the .vcproj files that I will have provided if 
I am capable to upload the zip file of UniMRCP 0.3.0 containing the 
changes described above. Note that in this zip file, “apr.vsprops” 
and “sofiasip.vsprops” reflect my directory structure, so you may want to 
change them. I am fairly sure that these project files are compatible with 
VS2005-base.

Of course, even if you agree to use the modified .vcproj, this doesn’t 
preclude calling Microsoft just for the sake of understanding what is 
going on.

There is also the option that you upgrade to VS2005-SP1, although a year 
ago or so, you tried and the program crashed, or did something similar, if 
I remember correctly. But perhaps, in the meantime you modified your 
computer or OS and this will no longer be an issue. I think that there are 
benefits of upgrading to SP1, at least as far as the speed of IntelliSense 
which seemed to take minutes, blocking the whole program when I was using 
VS2005-base.

Thanks a lot and best regards.

Original issue reported on code.google.com by Curat...@gmail.com on 4 Jan 2009 at 3:19

Attachments:

• ScreenShotsForNoCompilation.doc
• unimrcp-0.3.0[vlad].zip

[GoogleCodeExporter]

The sentence:

"There is a significant difference between a .vcproj file created by VS2005-
base and one created by VS2005-SP1".

should actually read:

"There is a significant difference between a .vcproj file created by VS2005-
base and one created by VS2005-SP1, after applying the changes outlined above".

Original comment by Curat...@gmail.com on 4 Jan 2009 at 3:31

[GoogleCodeExporter]

Vlad,
Thanks for the detailed description. I'll look at this during the days.

Original comment by achalo...@gmail.com on 5 Jan 2009 at 8:11

• Changed state: Accepted

[GoogleCodeExporter]

Vlad,
I clearly understand what you described, but this still isn't reproducible to 
me. I
have installed both VS2005 with SP1 and without SP1 on different PCs. Though I 
have
not experienced any problems in both cases. 
More over I can't find relevant information or anyone having similar problems
browsing the net.

Can you provide more information to understand what goes wrong on your side.

Have you installed any hot fixes or beta service pack before installing SP1? 
There is
an instruction to remove them first before installing SP1.
What version of VS2005 have you installed [Express Edition, ... Team edition]?
Have you experienced the same problem on different PCs with the same VS2005 SP1?

Original comment by achalo...@gmail.com on 9 Jan 2009 at 6:56

[GoogleCodeExporter]

Hi Arsen,

I don't want you to spend so much time with this issue. I am using VS2005 
Professional Edition and I have not added anything else before installing SP1. 
I am 
the only one here using VS2005, but I have a colleague running the free version 
of 
VS2008 and I have that at home, as well. I think, when I tried last year, 
VS2008 
didn't experience this behavior.

There are two actions we can perform:

1. You adopt the .vcproj files that I provided and check them in (if they seem 
to 
work as required).

2. I call Microsoft support and ask them. For me, the problem is easily 
reproducible 
by creating an empty project and then adding one .c file to the project. That 
file 
will contain the "Custom Build Tool” instead of the “C/C++ Compiler Tool” 
in 
the “Configuration Properties”. 

Let me call them first; perhaps there is a hidden configuration setting which 
controls this behavior. I will let you know. 

Thanks a lot and best regards.

Original comment by Curat...@gmail.com on 10 Jan 2009 at 1:21

[GoogleCodeExporter]

I wanted to migrate to VS2008 late in 2008, but postponed this to Q1 of 2009. If
VS2008 works for you, probably it makes sense to wait a bit.
I'm too close to release 0.4.0 version and prefer no to do last minute changes 
now,
but hopefully we'll have this fixed in 0.5.0

Original comment by achalo...@gmail.com on 10 Jan 2009 at 6:01

[GoogleCodeExporter]

Hi Arsen, I am sorry if I left the impression that I was pushing toward 
migration to 
VS2008. This was not my intention. In fact, there are still a large number of 
people 
using VS2003 in this world, I believe. 

If you do that, we will be compelled to migrate to VS2008 as well, because the 
project files generated by VS2008 will not be backward compatible with VS2005 
(most 
likely).

I will talk to MS support about the problem this week.

But if you really want to upgrade to VS2008, please let us know ahead of time 
so we 
can do the same and get used to the new environment.

Best regards!

Original comment by Curat...@gmail.com on 11 Jan 2009 at 2:05

[GoogleCodeExporter]

OK, Vlad. It makes sense to publicly discuss and understand all pros and cons 
of the
VS2008 migration later and not to mix this issue with the migration.
Waiting for further updates from you.
Thanks,
Arsen.

Original comment by achalo...@gmail.com on 12 Jan 2009 at 5:25

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 12 Jan 2009 at 8:20

• Added labels: OpSys-Windows, Priority-Medium, Milestone-Release-0.6, Component-Build

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 12 Jan 2009 at 8:21

• Added labels: Milestone-Release-0.5
• Removed labels: Milestone-Release-0.6

[GoogleCodeExporter]

Hi Arsen,

I think we can close this case. I still don't know why it happens but I found a 
configuration setting which will address the issue, without requiring to modify 
any 
UniMRCP project files. Just for your information, under Tools/Option there is 
a "Projects and Solutions" tag which has a sub-tag named: "VC++ Project 
Settings", 
which in turn contains a paramater named "C/C++ File Extensions". On my machine 
this 
parameter was set to "*.cpp;*.cxx;*.cc" by default (that is, without having 
been 
changed); I verified that with the tech support engineer from Microsoft. One 
simply 
has to add the "*.c" to those settings. I had done this a week ago but I 
started 
getting compilation errors after that without realizing that those error were 
caused 
by the uncustomized .vsprops files (header files not found).

Bottom line, the compiler "knows" (that is, it has the hardcoded information) 
that ".c" is a C file and not a C++ file (I verified that by using the 
keyword "class" in the "c." file, which caused a compilation error), but on the 
other hand, it pretends that it doesn't know anything about this file 
extension, 
unless it is specified in the configuration. But this is fine.

The only mystery is why everybody else seems to have the "*.c" in the 
configuration, 
and I do not.

Anyway, I marked the problem as "Invalid" since apparently is strictly confined 
to 
my own settings which for one reason or the other, are different than anybody 
else's 
settings. 

Very sorry for the troubles.

Original comment by Curat...@gmail.com on 13 Jan 2009 at 2:37

• Changed state: Invalid

[GoogleCodeExporter]

Hi Vlad,
It's really nice to have this issue resolved. I suspected that something went 
wrong
on your side, but didn't know how to address it.

Original comment by achalo...@gmail.com on 13 Jan 2009 at 5:29

[GoogleCodeExporter]

Final status of an issue should be "Verified". This concerns even "Invalid" 
issues.
So just mark this one as "Verified".

Original comment by achalo...@gmail.com on 5 Oct 2009 at 4:08

• Changed state: Verified