I've been given a Visual Studio project which has come with the following files:
myproj.def
myproj.dsp
myproj.dsw
myproj.idl
myproj.vcxproj
myproj.vcxproj.filters
After reading the Project and Solution Files Microsoft Docs it says for Projname.vcxproj:
The project file. It stores information specific to each project. (In earlier versions, this file was named Projname.vcproj or Projname.dsp.) For an example of a C++ project file (.vcxproj), see Project Files.
And this Microsoft Docs page says:
For convenience, Microsoft Visual Studio 6.0 provides a project file for each sample. This file has the DSP extension. An Allsamp.dsw workspace file is also provided in the main directory so that you can compile all the samples at once from within Visual Studio.
Does that mean that if I have the .vcxproj file, I can safely delete the .dsp and .dsw files?
Assume I do not care to ever recompile using Visual Studio 6.0 in the future.
.sln is equivalent to .dsw in VC6.0
.vcxproj is equivalent to .dsp in VC6.0
As far as I'm concerned ,if you have the .vcxproj file , you can safely delete the .dsp and .dsw files?
Related
Our solution contains a project type not supported on VsMac. It's a data tier app. In the solution file, there's the reference to the project:
Project("{00D1A9C2-B5F0-4AF3-8072-F6C62B433612}") = "SqlData", "Data\SqlData\SqlData.sqlproj", "{707B86CA-45F7-43C4-A9A4-CC2687E82056}"
EndProject
Is it possible to have this include for Windows versions of Visual Studio only?
The only option I'm aware of would be to use a separate *.sln file which is not optimal.
I just discovered a misterious file in my (new) Visual Studio 2012 C++/CLI project: app.aps.
I can find no reference on the internet about it. What is it meant for? Can I safely delete it? It seems so. Should I ignore or include in my commits to source version control?
It's a generated file for designer efficiency, you can ignore it in source control:
File created by Microsoft Visual C++, a software development application; stores the binary representation of a resource included with the project; enables the application to load resources more quickly.
http://fileinfo.com/extension/aps
APS files are the binary versions of resource files. As resource editor does not directly read the .rc and resource.h files, the resource compiler turns them into the APS file.
Reference - Files Affected by Resource Editing
I'm new in the world of Visual Studio. Can somebody please explain what these two files contain? I know that one of them contains info about project, but what about the other one?
A project file .vcproj / .vcxproj contains settings on how to compile your code into a DLL or a binary file, or something else that the linker can assemble into one unit. A project file is just an xml file that contains compiler settings, linker settings, and describes which files you want to compile.
A solution file *.slnis a text file that groups together multiple project files.
So if you think of it like a tree, then you have got a good mental picture of it like this:
.sln
.vcproj
.h
.h
.cpp
.cpp
.vcxproj
.h
.h
.cpp
.cpp
.csproj
.cs
Solution files and project files are in an XML format and describe the parts of your projects and their relations, configurations and so on. In fact, both of these files are simply MSBuild scripts (which are run through MSBuild when, you guessed it, building your project.)
This means they are easy to manipulate by hand if needs be (though this should be a rare case) and also allows to add custom parts to the build script, create custom build scripts for MSBuild that can include the solution file, among other things, or just simple auto-build scripts that pass the solution file (or project) to MSBuild, say, on version control check-in.
The difference between solution files and project files is that a project file holds information specific to that project, unaware of its solution (though, Visual Studio will look up the hierarchy to an extent in an attempt find the relevant solution when opening a project, if one exists); the solution file is aware of all projects that are part of that solution and references each of them (such as a directory of files, if you like, but with projects), it also contains solution-wide information / configuration, that can be applicable to all projects within the solution.
As pointed out by Hans Passant, there is an exception: files for C++ projects pre-VS2010 are not XML MSBuild files, but are instead a format documented by Microsoft on MSDN.
A .vcproj file contains information about HOW to compile source to a target (mostly, an executable). In many cases, it is crucial to have the project file for successful compilation, so do not delete it. It is compareable to a .dsp file (Visual Studio 6), a .prj file (Borland compilers), or a Makefile (Unix, GNU compilers) and contains paths and compiler/linker command-line options.
A .sln file is merely a collection of multiple .vcproj files. As Visual Studio can automatically create one if not present, there is no need to keep it for distribution or archiving. It's the successor of a .dsw file (Visual Studio 6). Its name "Solution file" is IMHO misleading.
In short: one is for solution, and the other is for project, and a solution can contain multiple projects.
Visual Studio allows multiple projects in a solution. The data what projects are in a solution is in the sln (solution) file.
I'm working on a script that generates Visual Studio 2005 C++ project files (.vcproj).
The script reads a makefile, then spits out a c++ project.
INPUT: makefile ---> OUTPUT: VS 2005 c++ project (.vcproj)
However, when I try to build the auto-generated project in VS 2005, error outputs: "Unspecified Error." Evidently, I am not generating the VS 2005 .vcproj file correctly.
Assuming that my c++ project file was malformed, I opened up VS 2005 and made a new C++ project. I actually copied the good, VS 2005-created project file to my non-working, malformed project file. I replaced the Name, Reference Includes (.libs), Compile Includes (.cc, .c), etc. in the good VS 2005 project with my malformed project file's information.
However, I still cannot get VS 2005 to compile my .vcproj. Perhaps VS 2005 is very particular about the content of its .vcproj's?
Please give me advice on how to manually generate a VS 2005 .vcproj.
Thanks!
The project files are in the MSBuild format, which is a XML file format with a schema (XSD). You can verify your generated files against this schema. Follow the instructions here:
http://blogs.msdn.com/b/msbuild/archive/2005/11/04/489212.aspx
to locate the schema files and then grab your favored tool schema verification tool to validate your tool's output. A discussion about schema validation tools is here:
XML Schema (XSD) validation tool?
We're using Jon Skeet's proto-csharp-port, and I'm running into some difficulties when mixing it with ReSharper in Visual Studio 2010.
We generate the .cs files via a custom MSBuild target, hooked up as follows:
<Target Name="BeforeBuild" DependsOnTargets="CompileProtos" />
The CompileProtos target runs ProtoGen and then adds the generated .cs files to the #(Compile) item group, by using CreateItem. This looks in a defined directory and compiles every .proto file it finds, so they're not listed in the project.
Where it falls down is that ReSharper doesn't recognise the content of the .cs files (because they're not in the project and might not exist yet), so I can't get the solution analysis light to go green.
If I add the .cs files to the project, then I get a build failure, because the .cs file has been added to the Compile item group twice.
I know that Marc's protobuf-net has Visual Studio 2008 goodness in it, and I'm looking for something similar, but for Jon's protobuf-csharp-port and for Visual Studio 2010.
Ideally, I'd like to be able to add the .proto files to the project, have them built correctly, and have Visual Studio and ReSharper know about the generated .cs files, so that IntelliSense and solution analysis work properly.
I'm guessing that something like how .xsd files can implicitly generate .cs files would do the trick.
I've attempted to get this working by implementing a custom tool for code generation, but I've run into a seemingly insurmountable hurdle:
protoc takes a directory full of .proto files and generates a .protobin file. This is then fed to ProtoGen which spits out a .cs file for each protocol definition. Unfortunately, it appears that the .protobin file needs to contain all of the definitions, otherwise you get Error: Unable to resolve all dependencies.
Since the custom tool model in Visual Studio assumes a single input file and a single output file (i.e. foo.proto -> foo.cs), it doesn't look like this can be made to work.
At least, not without finding some way to include all of foo.proto's imported .proto files in foo.protobin, anyway.
I solved it by removing the CreateItem from the CompileProtos target, and by defining it as a proper ItemGroup:
<ItemGroup>
<Protocols Include="$(ProtocolsPath)\*.proto"/>
</ItemGroup>
<ItemGroup>
<Compile Include="#(Protocols -> '%(Filename).cs')"/>
</ItemGroup>
This means that Visual Studio (and ReSharper) pick up the .cs files correctly, once they've been built, and ReSharper's full solution analysis stops complaining.
Unfortunately, Visual Studio has a habit of expanding the ItemGroup into individual Compile entries, but I can check for that before checking anything in.