I have a C# project that has multiple folders: Folder1, Folder2.
I added a shortcut in 'Folder1' to an xml file that is already in 'Folder2'. In this case when I compile the project the xml file will I have two copies in the assembly?
You were not clear with your description - did you reference the file with a shortcut, or did you add it to Folder1 by using the VS Solution Explorer and adding an existing item as a link?
The two methods are quite different. If you simply went into the filesystem and added a shortcut, then that is not automatically part of the project unless you specifically add it. And if you did add it, then it obviously can't be compiled, the best you could do is just have it set to No Compile and copy to the output directory.
If you added the file to folder one via the VS solution explorer and added it as a link, then it will be part of the project, and will be included twice, but it will be placed in Folder1 under the bin/debug or bin/release folder upon building. There will be no clash because they are in different folders, and they are not compiled, simply copied to the folder structure under the output directory.
Edit: and it won't be part of the assembly unless you set it to be a Resource or Embedded Resource. If you do that then yes, it will be in the assembly, but under two different resource paths.
In the Properties(context menu) of the selected file in the Solution Explorer change Build Action property to No Compile.
Related
I have Visual Studio 2017 project in which I need to open a folder named Devdog.General, which is also included in my Solution. However, it won't recognize it as an existing folder and gives me a missing directory / namespace error when I try to import it. See screenshot for more info.
Try this button:
I had a similar problem the other day and it had to do with files that Visual Studio didn't know were part of the project because they'd been created externally (and that included folders). Visual Studio could see them but it was hiding them from me.
After clicking that button, you will be able to right click on the folder and select "include in project" which will include the files for compilation and navigation.
First, try selecting any of your "*.cs" files inside this "General" folder and check in the "Properties" view if the Build Action is configured to Compile. Visual Studio will only compile your file if it has the correct build action.
Secondly, open that "*.cs" file and verify if the namespace defined inside it is correct. For C#, folder structures don't matter much: what really matters is the namespace you have defined your classes in. You can define your classes in namespaces completely different than the folder they are included in your project. That is completely arbitrary, and up to your organizational needs.
An image illustrating what you need to check (and where) follows.
Things to Check
1.) Check the namespaces inside .CS files - they collectively create usable namespaces you are referencing - not folder names. If you create a few files, then move them to a folder, and create newer files inside that folder they will have different namespaces. The newer files will have the default Namespace value followed by .FolderName. So be sure to check that out.
2.) CSPROJs can get hosed and lose reference to folders that display in the UI. Remove the folder from the project (through the VS2017 UI, right click and choose that option). DO NOT DELETE. Then recreate the folder in the UI (it shouldn't let you, navigate to the folder directory manually and rename the folder.OLD temporarily). Once the folder is rename, try recreating the folder. Upon success move all your CS files into the new folder from folder.OLD. After files and folders are back to where they were essentially, then in Visual Studio, "Add existing items" on your .cs files. This recreates the CSPROJ references one by one.
3.) Unload CSPROJ, right click and Edit CSPROJ to manually check all the .CS references in ItemGroups. Make sure its myfolder\myotherfolder\mycsfile.cs.
4.) Remove reference to other projects that contain namespace, and re-add them. Verifying, one by one, the namespaces begin reappearing in Intellisense as recognized.
5.) If you try the above step, close Solution, close Visual Studio, navigate to SLN folder container, and delete hidden folder .vs and then reopen everything.
What happens is sometime a folder rename or file transfer doesn't propagate to the .CSPROJ folder, a namespace then doesn't get intellisense cached, and errors galore show up.
Please check your folder name and namespace name. probably folder name and namespace did not match
enter image description here
So I've downloaded a framework to write code within, and I needed to link the source code to an executable file to allow the code to run. However, moved the root folder (containing all files related to the project) from the folder it was in previously, and now nothing works. I've been attempting to change the paths for the files to be relative to the root folder within the properties tab, but I'm not sure how to go about it.
Path to Executible - C:\Users\me\Downloads\Competition-Pack-v43-GeometryFriends-updated-14-08-2016\GeometryFriendsAgents\GeometryFriendsGame\Release\GeometryFriends.exe
C:\Users\me\Downloads\Competition-Pack-v43-GeometryFriends-updated-14-08-2016\GeometryFriendsAgents\GeometryFriendsGame\Release
Is there an equivalent to using Macros to define paths in C#, like you get when you build a C++ project?
Add the .exe as a resource (non embedded) to your project, and set the "Copy to output" property to copy always. This ensures the needed exe will always be relative to your build path. The simply use relative paths in your code.
Example:
(This is all done in VS's solution explorer window)
Right click your project, and add a new folder, name it Externals.
Right click the folder, click Add, and then Existing item. Locate your exe, and add it.
Now right click the exe, select properties, and set the "Copy to output" property to anything other than "Do not copy".
Now, anywhere in your code, use the path "Externals\YourExe.exe". The double backslash is to unescape the backslash. An alternative would be to use #"Externals\YourExe.exe", which turns the string to a path during compile time.
There you go, when you build, the exe will be automatically copied to the build directory's "Externals" directory, and always be relative.
It turned out in the end that Visual Studio has a Macros option for this very task.
When you're looking at your include directories window as in the image above, there's a button labelled Macros. Click that, and it gives you access to a list of predefined paths. They all start with a $, like the ones already provided that point to the include folders for Visual Studio.
In my example above, I added $(MSBuildProjectDirectory), which points to the exact folder that I needed on the drive my code folder was located on. Hope I can help at least one or two people with this, cause it drove me insane until I came across it.
I'm writing a C# project which I want to compile both under VS2010 and VS2012. I want to have two different .csproj files for that, even though VS2010-project can be directly included in VS2012-solution. I want two different project files because of different target .NET-versions.
Additionally, I want both projects to be named the same within different solutions for VS2010 and VS2012. The both should share the same .cs-files and, possibly, some resources.
Easy task? Strange thing, but I don't know, how to do that properly.
First approach, doesn't work: name project files as MyProject10.csproj and MyProject12.csproj, leave both in the MyProject folder. But in this case they are displayed in solution as MyProject10 and MyProject12, not simply MyProject. If I rename one to MyProject in solution explorer, it automatically renames the corresponding project file.
Second approach, works, but has drawbacks. Move project files into different subdirectories, named VS10 and VS12, manually change include paths in .csproj-files, adding ..\ as a prefix. In this case I see strange shortcut-like arrows under the icons in solution explorer.
The only bad thing for the second approach is that when I add new files in the project using solution explorer, this file is placed in the VS10 subdirectory, not in the root project directory. But it seems like project directories for .csproj-files are the directories containing the file by design, and I use the dark side of the force which I really don't want to do.
Any better ideas?
Worth giving a try is changing the name of the output assembly in both projects to one and the same. The project files are still going to be different, but the output assembly will be with same name. Also be carefull where is the output directory. I think this way you can sovle your problem.
I have an annoying error that's been popping up, and I don't know where it is coming from. The error is:
Error 31 Unable to copy file "app.config" to "bin\Debug\Framework.Tests.dll.config". Could not find file 'app.config'. Framework.Tests
The problem is, I don't have a bin\Debug folder anywhere, and it does not say from where it is trying to copy app.config. Double clicking on the error doesn't bring me to any code where it is trying to copy, so that doesn't help me either. So I don't know where I should make the app.config.
How can I find this out?
You have added a reference to a file called app.config or Visual Studio did this for you. The file does not exist on the disk, presumably because after adding the reference you later deleted the file.
Search for the missing file in your Solution Explorer, and either delete the reference or create the file.
It is most likely in the root folder of one of your projects, and should have a yellow triangle warning icon showing that the file is missing.
In an MSTest project the app.config is the one that you would like to provide any calls to the ConfigurationManager class.
It resides in the root of your test project.
The bin\debug folders will be created once the project compiles for the first time. Show all files in the solution explorer should help as they are not (and should not) be included in the project.
HTH
You probably do have a bin\Debug folder beneath your project folder, being the build target folder created by Visual Studio when you build your project for the Debug configuration.
My guess is that something (a test framework perhaps) still has the DLL file loaded, so Visual Studio can't delete and replace the existing Framework.Tests.dll.config file with the contents of your app.config. [Note: the project build action for app.config files is to copy it to the target folder renamed to match the executable with an extension of .config appended.]
I have a problem with resource files.
I have a solution with two projects. The first project contains ImageResource.resx file with the images that I use. Every Form in this project can access this file from the designer. But I can see in the designer ImageResource.resx file to use it from second project (Reference to second project is present).
I have added the ImageResource.resx file as a link to my second project. And I saw it in the designer! But when I use an image from this resource in the second project Visual Studio modified my original file (It sets the namespaces, and other..) and my solution breaks. Also Visual Studio tells me that ImageResource.resx is present in two dll's first_project.dll and second_project.dll
Can anybody help me with How to correctly use shared resources between projects?
The correct way to share resources is to create a global shared project. Create a new Project with the name Resources:
Next we must add some resources (such as icons) to the project. Do this as usual. Go to the projects setting, select tab Resources and Add Existing File… to the project. We can see that the icon is added to the project and was copied to the local folder:
Next step consists of adding this icon to the other project(s). Note the important difference, you need to add this icon as a link!
Adding as a link avoids the resource duplication. Create a new Project within the same solution and name it e.g. Main. Create some folder in this new project, naming it Resources (the logical name for our purpose). Then right click on this folder, select Add Existing Item… and choose the image file from the shared project folder. Make sure to use Add As Link here! If done correctly the icon of the newly added file will look slightly different (see below):
Added resource's icon must look like this
Now we must set the Build Action for this file to None. For this select the file and go to the Properties Window. There choose None for Build Action. We need to do this to avoid embedding this icon into the assembly:
Finally we need to add the linked files to the Resources of the corresponding project. Open the project Properties for the project where we just added the files. Choose the Resource tab and drag the linked file there:
These are the five simple steps you must perform to share icons between projects. You might ask "What are the benefits of this?" The benefits are:
We store resources in one place, and
It is easy to replace an icon with a new one.
This didn't work for me and I found another (VS2015+) approach.
See https://stackoverflow.com/a/45471284/4151626
In short, the shared project is directly included into the peripheral project. Thus, even though the IDE does not support <Resource> elements in the shared project. <Resource> elements can be added to the shared project, via a text editor. They are then incorporated into the peripheral project during the build.
(Apologies for the hyper-link. I would just repost the answer for clarity, but the stackoverflow editors crack down on this, deleting duplicate answers to save you from ???.)
Can you use a symbolic link to share the file into multiple folders?
windows:
mklink linked_location\ImageResource.resx original_location\ImageResource.resx
C:\Users\preet>mklink
Creates a symbolic link.
MKLINK [[/D] | [/H] | [/J]] Link Target
/D Creates a directory symbolic link. Default is a file
symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new link
refers to.
If a resource file is really shared between projects, you should put it in a shared project.
Solution 'Sample'
Project Sample.Data
Project Sample.Business
Project Sample.UI
Project Sample.Resource //shared resources are put in a shared project
You can't see the resource if it is not public, and it is default set to "Friend". You can set the "Access Modifier" in the Visual Designer (upper right-hand corner).