This is in VS2010 ...
I can't figure this out, but my assembly is not outputting a Properties folder with AssemblyInfo and the other bits that go along with it. I checked the csproj file and the following:
<AppDesignerFolder>Properties</AppDesignerFolder>
Is present, yet on build nothing gets generated. What am I missing?
The things in that folder are not generated during a build, they should exist and be included in the build. When you create a new solution/project, those files will be created. If you delete them, then you'd have to manually recreated them or copy them from a separate project (and update them).
The AppDesignerFolder just tells Visual Studio where it should look for some of the UI elements that can be used to update the files there (i.e. the version information in AssemblyInfo).
Related
I have developed an opencv application using windows form and C#.
The opencv packages I got from the Nuget packages manager (EMGU.CV and ZedGraph).
Everything works fine in visual studio, but when I publish the project and install the program in my machine, it throws an exception when I click a button that performs some opencv operations.
I guess the opencv packages didn't come along with the final published project, so how do I do to make it export when publishing, I thought it would be an automated process, I have already used other nuget packages and I had no problem with it.
What Am I missing here?
After some days waiting for an answer, and looking for solutions, I've figured it out how to solve this issue.
I came across this question:The type initializer for 'Emgu.CV.CvInvoke' threw an exception
Which led me to this: http://www.emgu.com/wiki/index.php/Download_And_Installation#The_type_initializer_for_.27Emgu.CV.CvInvoke.27_threw_an_exception.
More precisely this part:
First of all, I don't know why the compilation runs fine inside visual studio enviroment and why not when publishing the project as it is. For some reason, the Nuget packges are not enough for publishing the project, you need to add the .dll files manually yourself (not sure why this occurs once I have worked with Nuget packages before and this workaround was not necessary).
To find the .dll files you go to your project directory, then you go to bin\Debug\x64 or bin\Debug\x86 (depends on which operating system you are targetting - 32 bits or 64 bits -in my case I added all .dll files from x86 folder, I guess you can add from both folders if in doubt).
The Debug folder of your project is build every time you run the project inside Visual Studio enviroment, so if your Debug folder is empty then you just need to run the project one time to be able to find the auto generated files inside that folder. Just a side note here, you can use either the Debug or the Release folder inside bin, just remember to check if you compiled the project in Debug mode for Debug folder, or Release mode for Release folder, otherwise the desired folder will be empty, as explained before, I found no differences between the files generated, I added the dll files from Debug\x86.
Once you have located the .dll files, you go to Visual Studio, right click on the project in the Solution Explorer tab, then Add ---> Existing Item.
Go to the folder where the .dll files are, select all and click Add.
Once you have done this, the .dll file will be shown in the Solution Explorer.
Right click on each .dll file added in the Solution Explorer, and open the properties tab by clicking Properties. On the Properties tab, go to option Copy to Directory and change the field to Copy Always (the emgu documentation link provided above states to use the option "Copy if newer", but to make sure I chose "Copy always", it worked fine for me). Repeat the process for all .dll files added.
Now you are ready to go for publishing the project as it is,just remember doing this every time before publishing your project to see if no .dll files are missing, so once you got to final version of your program, run it, and then make sure to check the .dll files, it might have new ones to add or to remove.
I'm using Visual Studio 2015 update 3 with TFS hosted at visualstudio.com.
When I add a C# class file to one of my projects in Visual Studio, it's not automatically added to source control. For other projects in the same solution, C# class files are added automatically, as expected.
When I then add the file, manually, in the project with this problem, I get the following question;
I have to confirm to add the file to source control.
There is a similar question (Visual Studio 2015 new files not being added to source control automatically), associated with a "release" branch, which is not the case here (at least I think so - our TFS-project has never been branched)
We've never configured any .tfignore manually.
This started to happen recently and occurs on all development machines, so it's probably not a client machine issue.
I'm clueless, so any help is highly appreciated.
UPDATE
I've discovered that the problem occurs in projects with names ending with ".Lib"
Projects:
Core (ok)
Core.Lib (files not added automatically)
Communication (Ok)
Communication.Lib (files not added automatically)
I tried to add a test project Test.Lib to my solution. This project was not added to TFS either, but project Test was.
The "lib" extension is the problem. Try renaming the project folder to something else, eg. "CoreLib".
To reproduce this behavior / bug, try the following:
Create a Test directory in a directory controlled by TFS
Create a Test.Lib subdirectory in this directory.
Add a file, test.cs, to Test.Lib. (Test\Test.Lib\test.cs)
In Visual Studio's Source Control Explorer, try adding the new Test directory to source control. You'll see test.cs on the "Excluded items" tab.
The "lib" extension is used by binary files, and these are ignored by Team Explorer by default. I haven't found an official list of filetypes anywhere, but other affected file types are dll, exe, obj and possibly others. You can include these files manually by right-clicking them and selecting "Include".
I've search everywhere for this, but have yet to find the answer.
I have a VS2012 project with thousands of files and folders I wish to exclude from the project as I don't need them to build any longer. Clicking on the folder and choosing Exclude From Project works, but takes literally forever - at times it appears Visual Studio has stopped running and I have to kill the process.
Question: What is Visual Studio actually doing to exclude a file from a project? Is there a way to simply go into the project file and exclude the files by folder? My project file does not appear to store this information. Where are excluded files defined for the project?
You can open the project file (in s text editor, i.e. Notepad) and remove the lines with the files that you want to exclude.
You can also do that in visual studio but you first need to unload the project (right-click on the project, unload)
Delete the folder in VS which has project to unload then restore it from recycle bin.
It works for me.
In Visual Studio 2010 through 2013, by default (eg. When I create a new Console Application) new solutions output their compiled executable into Solution name/Project name/bin/Debug/. I want them to be output into Solution name/Debug/, and likewise for all other build configurations like "Release".
I can do this by manually going into properties of each project, going to the Build tab, changing Output path from bin\Debug to ..\Debug. I must repeat this for every project and every build configuration.
After dozens of solutions, I'm a bit sick of doing this tedious task by hand every time. Is there a way to change the default output path?
A solution that works for Visual Studio 2013 is sufficient.
This property is defined in each Visual Studio Project Template
So, for example, the C# Console Application template is located in
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj
The csproj is an XML file that you can edit at your will. The build output directory is define like this (for each configuration):
...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...
If you change this file, it will change all your future new C# Console Application projects. You could also write a utility program that list all csproj in \Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates and update them accordingly.
This is not necessary.
One of the projects in your solution is marked as the Startup project, shown in bold in the Solution Explorer window. An EXE project, like your console mode app. You used Project + Add Reference to add references to other projects in the solution so you can use the class libraries that those projects generate in your console mode app.
Those references will have the Copy Local property set to True.
When you build your project, MSBuild will automatically copy the assemblies from their respective bin\Debug directory into the bin\Debug directory of your console mode app, thanks to that Copy Local setting. And it is smart enough to also look at the dependencies of those class libraries and copy them as well.
So after the build is complete, the bin\Debug directory won't just have your console mode project's EXE file but also all the DLLs it needs to execute properly.
There are a few ways that this can go wrong and MSBuild cannot figure out that such a dependency actually exists. Pretty uncommon, you'd for example have to use Reflection in your code to load assemblies (Assembly.Load() and friends). The workaround for that is to explicitly copy the dependency in a post-build event. You didn't leave enough bread-crumbs in your question to judge whether that's the real problem.
What you ask for is certainly possible, the IDE just doesn't make it easy because it wasn't designed to assume this was necessary at all. You'd have to replace the Build + Output Path setting to, say, ..\Debug instead. You can create your own project template with that setting already preset. Create a new class library project, change the setting and use File + Export Template to create the template. You'll have it available the next time you create a project.
But, really, find out first why the default Copy Local machinery isn't working for you.
Rather than changing a global, protected file, you can create your own .targets file that changes the <OutputPath> however you want and import that into your projects. This could also set other defaults you might want to change and don't want to do for every project. All you'd have to do then in your project files is add something like toward the top (after the root element, of course):
<Import Project="$(SolutionDir)\Common.targets"/>
I created a C# project and added it to source control (mercurial). I can edit files in VS, commit it and push it using TortoiseHg. It goes to the server. When some one pulls they get the files.
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
However, now someone pulled the latest code from the server - and they got the new file (it is visible through windows explorer), but when they open the solution in VS, they don't see the file.
Does someone have an idea what is wrong here? or things I should check? Thank you for the help.
P.S. I have visual studio 2010 express (so I can't use the VisualHg plugin).
Visual Studio caches changes to the solution and project until an explicit save or a build. In your comment:
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
I see that an updated .sln or .vcproj file was not mentioned and checked in. Did you see an update to either of these files via TortoiseHg? If not, make sure to build or save your project after a change like this.
Did you make sure that the Visual Studio Project File or Solution file is being updated and committed?
VS solution contains projects and each project select managed files by metadata(***.vcproj file). It's not the way include all files from root directory.
So, your co-workers can see new added files by in following two ways.
1) share project file(***.vcproj)
2) manually add files in each person's VS instance.