I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.
Related
Coming from a Unix background and used to working with the Makefileto build stuff, I now have to find my way through the maze of twisty little passages known as Visual Studio 2017.
Basically: I just want to save a solution that I've imported into Visual Studio 2017 (e.g. to move it to another machine) to some sensible structure. I am unable to figure out how to do that!
The solution I work with comes from GitHub and the package is about 590 Kbyte and consists of 32 files. (I downloaded the .zip and unpacked it, then opened in the IDE by clicking on the .sln-file.
After running it (unchanged) in Visual Studio, it has ballooned to 4 Mbyte and 134 files. Obviously a lot of temporary files has been created as a result of me running it. Making a copy of this bloated directory structure is not practical - and some other way (i.e. the method for saving used by the guy who shared his solution on GitHub) must exist.
I want to save it with all those temporary files removed.
There is Build » Clean Solution – but it does not seem to get get rid of the temporary files.
I've also tried: File » Save all. I do no understand how this commend is supposed to work. It does not ask where to save tings, but just says "Item(s) saved" at the status bar at the bottom of the screen. Looking at things in the file system, I am unable to located anything saved. To me, it looks like this command does nothing.
I've searched, but so far found nothing for Visual Studio 2017 (recipes for older versions does not seem to work anymore.)
Saving a solution is something developers do a lot, so there must be something obvious I've missed.
There is not really the concept of "Save As..." for a solution. If you want to copy the whole solution elsewhere you would usually just copy the whole folder it's in to somewhere else.
The reasons you have many extra files are:
There will be a .git sub-folder which contains the Git repository. If you don't need to retain any link to this, you can delete / avoid copying this. Depending on how much history is in the Git repo this folder can even be much larger than the solution itself.
VS will create a .vs sub-folder for various housekeeping activities; you can usually avoid copying this.
In each project's folder, after you've built the solution, there will be obj and bin sub-folders. These are recreated as needed at build time and are not needed for a copy.
If you copy everything ignoring the above, you will probably find the size of the target is more as you were expecting.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
When I right-click my solution in the Solution Explorer and choose Properties I get a dialog where I can select the Startup Project.
I sometimes select Current selection (If it is an experimental solution with lots of projects I jump between), but most often it is a Single startup project selected, which would usually be the main WinForms applications or or Console application.
My problem is that whenever I do a treeclean with the tfpt command (Team Foundation Power Tools 2008) this setting is forgotten. So when I try to run my solution the next time, it has defaulted to some random project and I get an error stating that I cannot run a class library or something like that. Which is obvious of course. But where is this setting stored? Why is it forgotten when I do the treeclean? The solution file is still there, right? Isn't solution properties stored there?
Reference 1
Arian Kulp says:
I was struggling with trying to figure
out why a certain solution of mine
wasn’t starting right. It was in VB
with four projects. Upon initial open
it would set a certain project with a
DLL output as startup. If I set the
EXE as startup project, it was fine,
but when I distribute code I always
clean it by removing *.suo and *.user
files, and bin/obj folders. Upon
opening the “cleaned” version, it
would always revert to the DLL project
and fail to F5 nicely. The fix turned
out to be simple, though I’m curious
as to why I needed to do this at all.
In the solution file, there are a list
of pseudo-XML “Project” entries. It
turns out that whatever is the first
one ends up as the Startup Project,
unless it’s overridden in the suo
file. Argh. I just rearranged the
order in the file and it’s good.
I’m guessing that C# is the same way
but I didn’t test it. I hope that
this helps someone!
Reference 2
Setting the StartUp Project
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
I suspect that this setting is saved as part of the .suo file created whenever you edit a solution file. This file contains various user settings, such as breakpoints, watch data etc.
I cannot confirm this but that would be my guess.
Unfortunately its not XML its a binary file and not easily edited.
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
https://github.com/michaKFromParis/slnStartupProject
Forks and feedbacks are welcome.
Hope this helps!
I've got a solution containing multiple projects. I'm only changing the code in one of them, but every time I hit Ctrl+Shift+B, Visual Studio rebuilds all of the others.
I want it to build the other projects, so this is good. What's not good is that, normally, it would see that there was nothing to do. I have a wonky dependency somewhere, so this isn't working.
Is there a tool or macro (or switch) that'll explore the dependency tree and tell me which files are missing or out-of-date, so that I can get it to stop?
I know that I can solve this specific case, by (e.g.) touching all of the project files.
Unfortunately, I've often seen this situation when a file is configured to produce an output file (e.g. an IDL file is configured to output a typelibrary, but doesn't contain a 'library' block, so it'll never create a TLB).
This wouldn't be resolved by touching all of the project files, so I'm looking for something more general to add to my personal toolbox that'll easily tell me why a file is being rebuilt, whether it be because it's older than a dependency, or because the project is misconfigured to expect an output file that will never be produced.
In Options / Projects and Solutions / Build and Run turn up the MSBuild project build output verbosity to Detailed. It should give you an idea of why it is rebuilding all the projects.
If I understand you right, you might solve this by touching all your project's files. It may be caused by a source-file having a last-modified-time that's in the future.
Edit:
I know that I can solve this specific case, by (e.g.) touching all of the project files, but I'd like to add something to my personal box of tricks that I can use in the future, in the general case.
I'm confused - what's the 'general case' of this problem?
Not that I've found. If you know that a project is not going to change often, you can tell the Configuration Manager not to build it. (Right-click on the Solution, and select Configuration Management)
As far as I know ctrl + shift + b is by default bound to BuildSolution, so that would be why all your projects are being build. i'm not really sure what else you could use except for rightclicking the project and pressing build :)
You might want to check in Tools>Option>Projects and Solutions and check if your option is set to Only Build startup project and dependencies instead of all the solution.
Or instead of using ctrl+shirt+b you should simply press F6 on the project you want to build :)
You can use shift+F6 to build just the current project.
While not directly answering my question: "is there a tool that'll work this out for me?", I found the specific problem by using SysInternals Process Monitor:
The project was configured with /analyze, which requires Visual Studio Team Edition, but the version on this PC is Visual Studio Professional, which doesn't support it. Unfortunately, there appears to be a bug in Visual Studio, where it thinks that the .pchast file should be created, even though it has no way to do so. I've raised this on Connect.
I think I might write a macro for Visual Studio Professional that, if /analyze is turned on, simply creates an empty .pchast file at the end of the build...
I have experienced an annoying issue with Visual Studio 2005... sometimes when I rebuild, and even if I do a Rebuild Solution, it will come back with no errors or warnings, but then when I later edit another code file, even without changing it, and rebuild, it will find an error or warning in that other file. Clearly, the earlier Rebuild Solution did not recompile that file! How can I force VS to completely recompile every file?
I've seen this happen before when you have multiple projects in your solution and the references get mixed up.
Say you have four projects in your solution, Common, Business, Data, and UI. Assume that Common is referenced by the other three projects.
What we want is for Common to be a "project reference" from the other three projects - they'll then pick up their copy from the build output directory of Common.
But, sometimes, one of the projects will get it's reference mixed up. Say, in this case, that UI starts referencing the copy of Common in the build output directory of Data. Now, any change that compiles "UI" without also compiling "Data" will result in two, possibly incompatible, versions of "Common" being a dependency of UI.
Another scenario is where the reference is to a binary, such as from a "lib" directory. Then, one of the projects ends up referring to a build output location instead of lib.
I don't know what causes this - but I see it all the time, unfortunately.
The fix is to go through the references of each project and find the one (or more) that point to the wrong place.
It might help to clean the solution prior to rebuilding -- right click on the solution in the Solution Explorer and choose "clean solution" -- this deletes temporary files and is supposed to clear out the bin and obj folders, so everything is rebuilt.
I'm with Guy Starbuck here, but would add that Rebuild Solution is supposed to do a Clean Solution followed by Build Solution, which should, then, have solved your issue to begin with. But VS 2005 can be terrible in this regard. Sometimes it just starts working after several rebuilds. If upgrading to 2008 isn't an option, consider manually clearing the bin folder.
Is this related to the Configuration Manager? There you can select which projects in your solution build. Not sure if this helps.
Depending on the types of warnings it is not possible if I recall correctly.
For example, warning messages for XHTML compliance are ONLY displayed when the file is open. You might check the tolerance settings inside VS to see if you can change it.
This sounds strange - Rebuild should build everything regardless of changes and Build should only build things that have changed.
The behaviour you've described should only happen if you have modified something that is referenced by the unchanged file so that it is now incorrect.