This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.
Related
So I have a problem facing VS code changes.
Whatever changes I have applied to my solution and built, it is working fine and I can see those changes being applied when I debug. But the same changes aren't applying to the .exe file.
I have tried release build as well, Same with that. It Debugs the release build fine but doesn't apply those changes to the .exe file.
It Debugs the release build fine but doesn't apply those changes to
.exe file.
When you debug the project, VS debug engine will try to fetch the output project.exe and project.pdb for debugging. So if the debugging works well(those changes being applied), the output project.exe should also work without any issues(changes applied).
See this(for C++, similar situation with C#, VB):
This error message comes when VS debug engine can't find the output .exe, that's why I say if the changes are applied during debugging, it actually indicates the changes have been applied to your .exe file.
Let me name the project which outputs the .exe ProjectA, other projects in your solution are B,C,D. Here are two directions you can check:
If the code changes you mean is in Project A:
Right click project A in Solution Explorer=>Properties, check the value of your Output Directory(C++) or Output path in build tab(C#), it represents where the output .exe will actually exist, and VS debug engine will fetch the .exe in this path.
So make sure you tested the .exe in this path instead of old versions from other locations.
If the code changes you mean is in B,C,D, and A depends on B,C,D:
In most of the time VS will help copy the assemblies from B,C,D into A's bin folder, but I'm not sure if something's wrong with your environment which breaks this. You should make sure all the assemblies in your bin folder are updated.
I think this issue comes from your project instead of IDE(create a new simple project to check if the issue occurs in it). And in which way did you check if the changes are applied? Make sure you use the same way no matter checking during debugging or checking the .exe.
Updated:
According to Sandesh, this issue could be resolved by a clean(clean
old versions completely) rebuild.
Right click your project and click property, in General page, set "Enable Managed Incremental Build" as "Yes". It will replace the old exe file after every builds.
I would like to try and avoid the VB6.exe application when trying to compile my project. It tends to create the *.obj files and then crashes leaving me with no idea what went wrong.
"c:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /m MyProject.vbp
I would like to try and use LINK.exe and C2.exe to compile my application instead. I found a really great article located here on the process with all the switches etc. I was hoping someone has tried something link this and been successful so they can tell me exactly what switches I need to use and a step by step process of how to create the object files and then link them all to the EXE.
I ended up getting this old source to compile. I'm sure my situation was unique but I thought I would share in hopes of helping someone else find their way if this happens to them.
First, I could NOT get this one project to compile to save my life in the end. At first it would compile in the IDE, then only by running the following in a command line...
"c:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /m MyProject.vbp
Then that would not even work and I had to use the package and deployment wizard to compile it which worked some of the time.
I think it was really just hit or miss in the end. But at some point something pointed to a specific module file I had that was used to access (read/write) the registry. I think it was between looking at logs and maybe even the windows event viewer etc. So I started thinking... Maybe it will compile if that was not used. So I removed the module from the project, tried to compile, then VB was nice enough to show me every call that would not work because the referenced function did not exist. I commented out all of those as well then I was able to compile with very little effort and it went smooth again!
So that helped me identify what VB was flipping out about but it did not solve the underlining issue (that I could not compile ALL of my source). So I started trying to work all the source back into the application one by one to see where it would break at.
I first added the module file to the project and just compiled.
Success!
I then tried to uncomment the first thing I commented out (reference to the function in that module) and then recompiled.
Success!
I managed to get all the way back through all my commented out lines of code and put them back the way they were originally. I then recompiled for the final time.
Success!
So at this point I had EVERYTHING back to the exact way I had it before I started trying to compile. Now it works with no issues at all!
I am new to ANTLR. I wanted to learning start by setting up a project so that lexers\parsers would be automatically generated by the build. So I downloaded antlr-dotnet-tool package, modified a project file to include antlr targets. I also installed some VS extension that add syntax highlighting and new item types for grammar files.
Now, generation seems to works, but it puts output files into obj/${Configuration} folder. And I don't really know what I am supposed to do with them there. Surely, you don't want me to manually copy them to proper locations (supposedly next to grammar files), do you?
It would be great if you could shed some light on it.
If you followed my blog post, you will see that you need to do nothing else,
http://www.lextm.com/2012/07/how-to-use-antlr-on-net-part-v/ (note that at the beginning you will see links to the previous 4 parts)
At compile time the generated files are automatically linked to the output assembly, and the debugger is capable of loading them when you debug the program.
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.
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!