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!
Related
I know I will miss so much of Visual Studio but I am getting really sick of it crashing all the time and being slow, PLUS it is always changing things in my repository that I don't want to change, so I want to just edit with Notepad++. However, now I will have to load up VS just to build things. Is there a way I can build from command line and make a script for it and what not? Will it show the compile errors?
Please don't try to troubleshoot VS for me, I am just asking what is in the question and the rest was just given for context and so nobody was like 'Y U NO RIKE VIZAL STUDIA?'.
build: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "PATH TO YOUR SOLUTION FILE"
help: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /help
What you need is directly calling csc.exe, the C# compiler (which is called by the build system of Visual Studio, anyways). If you ever worked with GCC, it is quite similar except that options are passed Windows-style with / signs instead of -- and there are no object files or additional linking. The MSDN library has documentation: http://msdn.microsoft.com/en-us/library/78f4aasd.aspx.
Generally, you'd need something like:
csc /target:exe /out:Something.exe *.cs
plus any /reference's you would add in Visual Studio.
If your project is large, it may be uncomfortable to maintain a .bat file to do the compilation, so a build tool like NAnt may be needed, which is quite similar to the Ant used for Java.
This is of course if you want to eliminate Visual Studio entirely. Otherwise, Snowbear's solution of invoking MSBuild.exe will be just as fine.
In a specific partial view, I consistently get a message in the breakpoints I set:
"The breakpoint will not currently be hit. No symbols have been loaded for this document."
Is there any reason for this to happen? What may I have done?
I restarted Visual Studio and I even restarted my computer, but it didn't work.
What do I have to do to debug this page?
Thanks!
Edit
I edit the partial view file with which I am having problems, but the changes do NOT take effect. So, somehow, that bastard compiler is getting the file from somewhere else. Where?!
I had the same situation after modifying a view that used to debug ok. I reverted my changes and debugging resumed working. I found I had a syntax error on a line. There was no clue it was wrong - there was no red underlining and the project compiled fine.
If you have the problem in your view, I suggest commenting most of the code to a minimal skeleton. If debug works again, uncomment some of your lines back in until you find the problem code. Good luck with that.
There are several possible reasons for that:
The version of the source file is not the one you compiled. Try to recompile.
The DLL containing the code is not loaded in the program at runtime. Use the program in a way that the DLL will be needed if you have dynamic loading of DLL.
You are visualizing a source file which is not in the right directory (another copy of the solution somewhere else on the hard disk). Open the right source file.
You didn't compile the program in debug mode. Recompile it in debug mode.
You didn't launch the program in debug mode. Launch it in debug mode.
This is happening to me too...it's a real pain in the arse. The reason is because your PDB files are missing from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root[random][random]\assembly\dl3[random][guid]
I have about 30 DLL files that get built with my project, I have to go into each one of those stupid temp directories and copy the PDB file for each DLL from my VS build bin. I've posted questions on here about it too but haven't gotten any help. For a quick fix, you can try to copy your matching pdb files over but I'm telling you it's gonna get old real fast.
Someone else in my office has fixed the problem by using the "Publish" feature in Visual Studio and publishing their site straight into a web directory but I haven't had any time to mess with that yet. Someone else has told me that it's a x64 bug in Visual Studio but I find that hard to believe considering how crippling it is.
The way I resolved it is by going to the properties(F4) of the file and set the value of Build Action to Compile.
Summary
I want to alter the build process of a 2-assembly solution, such that a call to ILMerge is invoked, and the build results in a single assembly. Further I would like to be able to debug into the resultant assembly.
Preparation - A simple example
New Solution - ClassLibrary1
Create a static function 'GetMessage' in Class1 which returns the string "Hello world"
Create new console app which references the ClassLibrary.
Output GetMessage from main() via the console.
You now have a 2 assembly app which outputs "Hello World" to the console.
So what next..?
I would like to alter the Console app build process, to include a post build step which uses ILMerge, to merge the ClassLibrary assembly into the Console assembly
After this step I should be able to:
Run the Console app directly with no ClassLibrary1.dll present
Run the Console app via F5 (or F11) in VS and be able to debug into each of the 2 projects.
Limited Success
I read this blogpost and managed to achieve the merge I was after with a post-build command of...
"$(ProjectDir)ILMerge.bat" "$(TargetDir)" $(ProjectName)
...and an ILMerge.bat file which read...
CD %1
Copy %2.exe temp.exe
ILMerge.exe /out:%2.exe temp.exe ClassLibrary1.dll
Del temp.exe
Del ClassLibrary1.*
This works fairly well, and does in fact produce an exe which runs outside the VS environment as required. However it does not appear to produce symbols (.pdb file) which VS is able to use in order to debug into the code.
I think this is the last piece of the puzzle.
Does anyone know how I can make this work?
FWIW I am running VS2010 on an x64 Win7 x64 machine.
Update: Why do I want to do this?
It's been asked: 'Do I really need to ILMerge during the debug scenario?'
The assemblies of my solution will need to coexist in the same folder as those of other solutions (some of which I will likely develop)
Some of these solutions will share dependencies on different versions of some assemblies.
So Solution1 might be made up of Console1 and ClassLibrary1.dll(v1) and Solution2 might be made up of Console2 and Classlibrary1.dll(v2).
Rather than register everything in the GAC, I thought I could ILMerge the correct version of a dependency into the primary assembly of the solution to avoid a collision.
However this currently renders it impossible to debug the solution, which I need to do in place in conjunction with the other solutions which will be present.
Does this sound complicated? That's because it is.. :D
I'm sorry you're having problems. I didn't follow your exact steps, but I created a console application, A.exe, that called a method in a dll, B.dll. I built both assemblies in Debug mode (so that they had PDB files). I then merged them like this:
ilmerge /out:foo.exe A.exe B.dll
(Actually A and B were in another directory so my command line was a little more complicated, but that shouldn't make a difference.) After ILMerge completed, there were two files in the current directory: foo.exe and foo.pdb. I then typed:
devenv foo.exe
This opened up Visual Studio and then I hit "F10" to start the debugger. I was able to step into the Main method in the executable and then used "F11" to step into the method in that had originally been in B.dll. The debugging experience was just the same as it had been in the original Visual Studio solution with the two assemblies.
If you are still having problems, please feel free to put your entire solution into a zip file and send it to me (mbarnett at microsoft dot com) and I can try it out.
I would suggest that you only ILMerge release builds of your assemblies. I can't imagine any benefit you'd get from merging debug assemblies.
I tried to do something like this and found that you should not rename anything, neither before not after the merge. Moving stuff to to separate directory is fine. If you do not rename anything, it works.
If you are still using ILMerge, like I am, there is also an another solution to debugging issues. At least for me the dubugging started working after NOT using the portable PDB format. My project is .NET Standard 2.0 and I was running it under .NET Framework.
I don't think ILMerge can do it. OTOH smartassembly from red-gate (not free) can do it, at least so it says at features
And yes, I do agree with Mike to only use ILMerge for release versions.
my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does.
What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file.
Foo.dll (release configuration, compile)
Foo.pdb
Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ...
Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ...
I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question).
Can someone help me please?
Yes you can, if your friend indexes those PDB's, so that the debugger knows where to find the appropriate source in a source-control system, and if your friend uploads those pdb's to a symbol-server, you can perfectly step through the code while debugging.
I have done this for some projects at work, and this works like a charm.
More info about setting up a symbol server:
Source server helps you kill bugs
Setting up a symbol server
Using symstore
The answer is in in the linked question, though perhaps it's not blindingly obvious, so I'll say it: yes, you need to have the source code in order to step through the source code. The PDB file only tells the debugger what line of what source file corresponds to a particular machine instruction.
You don't need to set up a "symbol server" or anything like that. Just get him to send you the source. When you load the PDB file Visual Studio will prompt for the location of the source files if they're not at the same path.
I guess you posted link to another question just to prove that you have searched because that question does have an answer to your question.
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.