I've added a bunch of files from my older project into my new project. They're still not playing an active role in my current code and there are missing classes that won't make them fully functional anyway, I just want them there so I can gradually rework each file to be compatible with my newest code. Is there a way tell the compiler not to pay attention to these C# files and report errors?
P.S: I'm using SharpDevelop
Have a look on the File Properties for
BuildAction Property
The BuildAction property indicates what Visual Studio does with a file when a build is executed. BuildAction can have one of several values:
•
None - The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.
•
Compile - The file is compiled into the build output. This setting is used for code files.
•
Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file.
•
Embedded Resource - This file is embedded in the main project build output as a DLL or executable. It is typically used for resource files.
use c# preprocessor directive #if then put that conditional variable inside Compiling/General/Conditional Compiling Symbols
http://msdn.microsoft.com/en-us/library/aa691099(v=vs.71).aspx
Although it is possible to give specific compiler instruction, I'd remove the files from the solution and put them somewhere safe in version control.
Having these files in the solution can easily be confusing when browsing the sources; I would not expect to have to check the BuildAction property of C# files to find out whether or not I am looking at something that is part of the build.
I read a lot of code in a source control viewer (looking a delta's and history), compiler options are not very obvious in environments like these.
Put them safe in source control and remove them from the build.
Related
I'm trying to reference a C# DLL project from another solution, but the build is generating the DLL in a very strange output folder.
The directory contents is this:
c:\a\b\c\src\Solution.sln
c:\a\x\y\z\MyDLL\MyDLL.csproj
The MyDLL.csproj does not have an <OutputPath> tag. It does however have a <SolutionDir> tag that I don't see often.
The computed output path, as shown in Properties view, happens to be:
..\..\..\..\b\c\src-z\MyDLL\objd\i386
This corresponds to this path:
c:\a\b\c\src-z\src\MyDLL\objd\i386
which is very weird, since I'm not aware of anything in configuration with src-z. Is Visual Studio computing a path with hyphens?
I want to fix this, possibly changing the <SolutionDir>, but I don't want to break other solutions.
The computation seems to happen very early in the build process, as the first thing the builder logs is:
1>Project 'MyDLL (x\y\z\MyDLL\MyDLL.csproj)' is not up to date.
Input file 'x\y\z\MyDLL\MyDLL.csproj' is modified after output
file 'c:\a\b\c\src-z\src\MyDLL\objd\i386\MyDLL.pdb'.
So what algorithm is Visual Studio using to compute the output path when a project <OutputPath> tag is not found?
The code that populates OutputPath can be found in C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.CurrentVersion.targets (by default; it may change if the MSBuild install directory is different).
There is a comment about it that reads:
OutDir:
Indicates the final output location for the project or solution. When building a solution, OutDir can be used to gather multiple project outputs in one location. In addition, OutDir is included in AssemblySearchPaths used for resolving references.
OutputPath:
This property is usually specified in the project file and is used to initialize OutDir. OutDir and OutputPath are distinguished for legacy reasons, and OutDir should be used if at all possible.
So while OutputPath is often what is referenced, it is OutDir that actually matters. If there is no set platform or configuration then OutputPath is set to bin\Debug\.
If we look in that file we can see the logic that sets OutDir is pretty simple. If OutDir isn't set then it is set to OutputPath. There is a little bit of extra logic around appending a folder named after the project to the path if GenerateProjectSpecificOutputPath is set.
Looking at Microsoft.CSharp.targets, Microsoft.CSharp.CurrentVersion.targets, Microsoft.Common.Targets and Microsoft.Common.CurrentVersion.targets, neither OutDir nor OutputPath appears to be set anywhere else. So, assuming an "out of the box" C# project, it basically will equal either OutDir, OutputPath, or bin\Debug.
The last bit of information that is relevant is the working directory. OutDir can be a relative path in which case it will be somewhere in the working directory.
As for the BaseIntermediateOutputPath, the information is in the same file:
BaseIntermediateOutputPath:
This is the top level folder where all configuration specific intermediate output folders will be created. Default value is obj\
IntermediateOutputPath:
This is the full intermediate Output Path, and is derived from BaseIntermediateOutputPath, if none specified (eg. obj\debug). If this property is overridden, then setting BaseIntermediateOutputPath has no effect.
Looking at the logic, it defaults to obj\ if not set (note, relative path so the working directory comes into play again).
I would say you have an OutputPath declaration somewhere but if not in your .csproj file in one of the imported targets-files.
I will split my answer in several parts:
<SolutionDir> tag and changing it.
With this tag you can declare the solution directory variable $(SolutionDir), but I don't think it is used by Visual Studio from inside the .csproj file if it is different from where the solution actually resides.
But the tag could be used by MSBuild builds. I couldn't get Visual Studio to use it if I declared it in the .csproj file.
Visual Studio uses the directory of the loaded solution as variable content instead of any different declaration in the .csproj file from my tests.
Having said that: changing the tag will probably change the use of $(SolutionDir) variable in any places where you use it like PreBuild/PostBuild or Output directories. Whereever it is used. But not in Visual Studio.
If it is not used changing it won't change much in Visual Studio builds.
No OutputPath tag
I would expect this tag if the .csproj file is loaded inside Visual Studio. But it is possible to declare it in targets-files instead of .csproj files. So you have to check the imported targets files as well.
e.g. Look at the file Microsoft.CSharp.targets. This is the standard imported targets file for CS-Projects in Visual Studio. It makes computations and declarations of OutputPath.
Second possibility to look are your own targets files that you can import (handwritten .csproj files). Declarations are possible there as well.
Third possibility: I think it is possible to declare this variable via command line argument for MSBuild though not for Visual Studio.
Would Visual Studio work without this tag in the .csproj file?
Usually not, BUT you could declare to override errors from the standard C# targets file (Microsoft.CSharp.targets) and make it build - but then it is declared in this file.
Standard Output directory if not declared would be \bin\Debug (for debug builds) as defined by Microsoft.CSharp.targets.
Otherwise you get an error. Missing OutputPath declaration.
How is it computed
Look at the .csproj file and targets files (excluding command line parameters in MSBuild) and see which PropertyGroup sections are valid (check the conditions).
For example:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
</PropertyGroup>
Everything inside this would be valid for the selected configuration Debug and AnyCPU. Especially in the standard targets file there are a some declarations for OutputPath.
This is where it seems to get non-standard for you if your information is correct: Usually you get an error in Visual Studio building if OutputPath is not declared because there is a section
in targets checking the declaration and throwing an error (you can change this behavior - see point 3). Interpretation would be top-down like any script.
src-z comes from where? (in Visual Studio)
Scan all .csproj files and targets files you are using for "src-z" and the hard disk location of the solution file to find out where it comes.
If you really don't have any OutputPath declaration anywhere then I don't have an explanation why your VS-Build is working.
And if you don't find src-z then can you post some more information on your .csproj file and how you use it (Visual Studio and solutions)?
I found the issue. One of the referenced projects was defining <BaseIntermediateOutputPath> as $SolutionDir + "-" + $ProjectName, which yields to c:\a\b\c\src-z.
As for answering my question, the best I could deduce is:
If there is <OutputPath>, then it's used.
Otherwise, the output path is defined as <BaseIntermediateOutputPath> + <IntermediateOutputPath> + "bin".
The default value of <BaseIntermediateOutputPath> is the project directory.
The default value of <IntermediateOutputPath> is defined by the build type (i.e., Debug, Release, etc.).
For the project I'm currently working, I am creating resource files (.resx). I am using Resgen.exe and AL.exe to create .resource and .dll files. The Build Action for the .resx files is set to "None".
The idea is to allow customers to provide their own localization if what we provide does not suit their needs.
The problem I'm having is that the .resource files are absolutely necessary in the delivered product. I was under the impression that the .resources.dll file be sufficient. Are the .resource files really needed in the finished product or am I doing something wrong?
EDIT: I have recently discovered that helper files were specifically looking for .resource files. I have modified the code to use the .dll, but now strings are not being returned. So now my question is "how do I access the .resources.dll to retrieve the strings?"
Are you following a guide that says to set the build action to None? That seems like a mistake to me. If the build action is set to none, then it cannot be included in the library assembly.
I would try setting them to Embedded Resource.
Is it simple or even possible?
Why: Following my other question and using this approach, now I would like to simply embed the source file to the resources so I can copy it to the temp folder while the application is running - and keep the application as a single file.
I assume using a pre-build event is the best way to do this. If so, how would it be done?
EDIT: I'm asking about adding it before building because I also assume it won't be automatically updated if I add it manually once and then change the code after.
I recently went through this same issue when developing an examples suite for a .NET control which had to display its own example source code in the application.
The approach I ended up with was as follows.
I created a batch script (run in pre-build) to copy all the code files under /Examples/* to another folder in the solution Resources/ExamplesSrc/*
I then included all these files under Resources/ExamplesSrc/* in the csproj and saved it.
The next step was I set all the files under Resources/ExamplesSrc/* as embedded resource and committed the change to SVN. I did not commit the examples (generated) to SVN, just the modified csproj and batch file.
The effect when developers checked out was that they had (!) icons on all the resources (they were not on disk, but the csproj was looking for them), however as soon as they built the generated files appeared and all was well. This approach also worked with a build server (Team city) and the examples suite can now load and browse its own code via embedded resources.
One caveat you should be aware of. There is a quirk (by design apparently) in VS2010. If an embedded resource has ".cs" in it (i.e. any code file!) it cannot be loaded from the assembly using Assembly.GetManifestResourceStream(). To work around this all source files were renamed in the batch copy step from *.Xaml.cs to *.Xaml.c.txt, from *.cs to *.c.txt
Hope this helps!
Turns out I don't need to (re)add the source file each time I build the solution!
When I add it manually once it becomes a "Text" file on resources - and I can easily access it as a string using Properties.Resources.SourceCode (having the file named "SourceCode.cs"). And yes, it is updated automatically since the resource property "Persistence": the file is linked at compile time.
I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?
A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.
No, you don't want random files that happen to be in the project directory included in source control.
We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).
Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.
When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.
If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.
One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.
I have an image that is used in some PDF files that my C# application generates. I know how to reference the image file when it is located in my workspace, but when I compile the program, I don't see the image anywhere in the compiled directory.
Can someone tell me what happened to that file, or do I have to manually package the file along with my program when I send the program to the users? I added the image to the workspace by drag-drop to the resource directory of one of my namespaces.
Check the file's properties in Visual Studio. Have you set the CopyToOutputDirectory property to something besides Do not copy?
Hmm... I'm not sure about the whole drag-drop business, but if it's all working the resource will have been embedded into your assembly.
I suggest you have a look with Reflector - you can see the resources embedded within assemblies using that.
Have a look at the build properties for the item in Solution Explorer - in particular, if the build action is Embedded Resource then it will indeed be built into the assembly.