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

[achaloyan]

Originally reported on Google Code with ID 10

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.

Reported by Curatica on 2009-01-04 03:19:50

---

- _Attachment: [ScreenShotsForNoCompilation.doc](https://storage.googleapis.com/google-code-attachments/unimrcp/issue-10/comment-0/ScreenShotsForNoCompilation.doc)_ - _Attachment: [unimrcp-0.3.0[vlad].zip](https://storage.googleapis.com/google-code-attachments/unimrcp/issue-10/comment-0/unimrcp-0.3.0[vlad].zip)_

[achaloyan]

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".

Reported by Curatica on 2009-01-04 03:31:32

[achaloyan]

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

Reported by achaloyan on 2009-01-05 20:11:52

• Status changed: Accepted

[achaloyan]

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?

Reported by achaloyan on 2009-01-09 18:56:41

[achaloyan]

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.

Reported by Curatica on 2009-01-10 01:21:10

[achaloyan]

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

Reported by achaloyan on 2009-01-10 06:01:02

[achaloyan]

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!

Reported by Curatica on 2009-01-11 02:05:57

[achaloyan]

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.

Reported by achaloyan on 2009-01-12 05:25:28

[achaloyan]

Reported by achaloyan on 2009-01-12 20:20:59

• Labels added: OpSys-Windows, Priority-Medium, Milestone-Release-0.6, Component-Build

[achaloyan]

Reported by achaloyan on 2009-01-12 20:21:25

• Labels added: Milestone-Release-0.5
• Labels removed: Milestone-Release-0.6

[achaloyan]

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.

Reported by Curatica on 2009-01-13 02:37:29

• Status changed: Invalid

[achaloyan]

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.

Reported by achaloyan on 2009-01-13 05:29:59

[achaloyan]

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

Reported by achaloyan on 2009-10-05 16:08:30

• Status changed: Verified