I recently finished a solution composed by 2 project. For this 2 project I have the .exe build, but I don't know how to do the exe of solution with VS 2012. Someone know how to do it?
When you compile & build a solution, the .exe that is created is placed into the folder relating to your current build configuration, usually either Debug or Release.
So navigate to the folder, on disk, using Windows Explorer, where the solution is stored, and look in the Debug folder. The compiled program is there.
If this is not what you are after, please post more details about these two projects and how they 'tie together'.
Related
Just wondering if there is a preference between sln or csproj files when building projects in TFS 2012. We typically build sln files in TFS to support our dev teams and that's usually the standard, but one team is asking why we can't build csproj files instead in TFS.
I noticed that to build a csproj file you have to provide arguments in the MSBuild Arguments field for a TFS build definition, and you do not have to provide these arguments when building a solution file. So other than this small detail I'm not sure what the pros and cons are between building an sln vs csproj.
Can someone please shed some light on the benefits, pros/cons of building a sln vs csproj in TFS, is there a common practice, a standard, or does it really matter?
Just wondering if there is a preference between sln or csproj files
when building projects in TFS 2012. We typically build sln files in
TFS to support our dev teams and that's usually the standard, but one
team is asking why we can't build csproj files instead in TFS.
Why do they want to do this? Is there some sort of advantage articulated in this inquiry?
I noticed that to build a csproj file you have to provide arguments in
the MSBuild Arguments field for a TFS build definition, and you do not
have to provide these arguments when building a solution file. So
other than this small detail I'm not sure what the pros and cons are
between building an sln vs csproj.
A .sln is a master project that is converted to an msbuild script at runtime and will use a metadata file using the same schema as the .csproj projects in your solution.
To see what I'm talking about, open a command prompt, type "SET MSBUILDEMITSOLUTION=1" then "msbuild.exe solution.sln", then parse the new "solution.metaproj" and "solution.metaproj.tmp" files.
Can someone please shed some light on the benefits, pros/cons of
building a sln vs csproj in TFS, is there a common practice, a
standard, or does it really matter?
A .csproj would be a single project while a .sln would be a collection of projects. Building a single .csproj would yield the output binaries of that project (along with dependencies) and building the entire solution would yield the outputs of the entire solution.
I had the same question. Build times may be a bit slower but I haven't tested this myself (probably a negliable difference). I believe that when you build using the solution file it will automatically set 'BuildInParallel' to true.
Faster Buidls with MSBuild
I am currently working on the TFS 2012 deployment build. Based on what I experience, you don't have to provide MSBuild Arguments unless it is really required.
Lets take the following example: You have a solution with 2 projects,
Soln
> Web Proj 1
> Console Proj 2
> Dependency Library Folder
case 1: building a sln
a. In source settings, you have to mention only your solution folder. The MSBuild will automatically take care of any dependencies as they are within the solution.
b. In Process -> Items to build, you have to mention your solution file.
c. For example, if your solution has a web project, then the MSBuild output will be as shown below,
\\<build server> \d$\Builds\<Build Name>\<Build File Name>_20141210.6\_PublishedWebsites\<web proj>
Case 2: building a csproj
a. In source settings, you have to mention only your csproject folder and also the dependency folder path separately.
b. In Process -> Items to build, you have to mention your csproject file.
If you are looking for something more specific, please let us know.
I have a solution with reference to Telerik assemblies. The referenced version has been installed on the build server. The issue is that the continuous integration build always succeeded until I upgraded the Telerik assemblies in the solution and on my build server. The build now fails giving the classical:
Could not resolve this reference.
I checked my solution and everything is set to reference the specific version. The most suprising is that if I open the solution locally on the build server, everything will build without a problem... so that means the Telerik assemblies have been published somehow, but for an unknown reason, when MSBuild is called to compile the solution throught the build service, it does not work.
Any ideas?
I had the same problem after updating to the Q3 release.
To solve this, I built the solution with Logging Verbosity set to Diagnostic, and found that MSBuild never bothered to look in the Telerik folder.
So to include that folder in the build, we simply added it by adding a MSBuild argument:
/p:ReferencePath="C:\Program Files\Telerik\RadControls for WPF Q3 2012\Binaries\WPF40"
It's perhaps not the best, and needs to be updated everytime you update RadControls, but it works.
We run the build server on a x86 installation, so Telerik is located under C:\Program Files, but if you run on a x64, it's under C:\Program Files(x86), so if you run several build servers on both x64 and x86 installations, you must specify both path.
Try to remove-then-add reference to updated dlls - you can then see in proj file if there any differences with referenced assembly.
Enable verbose\diag mode for msbuild (/v:diag command line key) and check build logs. Diag mode have very detailed output about referenced library search process.
I normally find it's better to copy the referenced assemblies into the solution and reference them from there. Then the build server and other developers don't need to worry about installing that specific version and you can support multiple projects running different versions of the component.
when i try to run a application developed in vc++ on windows7,i get popup window saying that"the program can not be started because MSVCR80D.dll is missing from your computer,try reinstalling the program to fix this issue."
I googled it,it says that this DDL may not be present in your system or it has been got corrupted,Now i searched this file, i get this file at 20 different folder in win7.
I am not getting which file has been corrupted or if it is missing then where it is mising?
can anybody tell in which folder ,this DDL is missing or might be corrupted?
Thanks in advance. .
You're trying to run a Debug version of your program on a machine which does not have VS installed. The MS*D.dll files are not redistributable - they are installed were VS is installed. If you want to run executables on other machines, compile them as Release. You might still need to deploy some files (depending on how you're linking to the CRT), but that won't be a problem.
Never ever distribute your DEBUG builds to customers. Always distribute Release build.
Yes, of course, in develoment environment having multiple machines, you may share Debug builds to other developers - provided others developers have debugging-tools (like VS) installed on their system along with Debug-binaries of shared DLLs (like MSVCRxx).
Are you using the same computer that compiled the program? If not, you need visual studio redistributable files to run it.
Search the internet for your version of visual studio or visual c++ redist, you'll find it.
Unfortunately this is going to be a pretty open-ended question, but I am at my wit's ends and I thought I would reach out for some advice.
This is a Visual C++ MFC app using Visual Studio 2008 SP1.
A coworker and I both had Office 2007 installed and we have both had strange DLL loading problems with our app since. Specifically, LoadLibrary is failing to load one our DLLs ( the first one it loads ) and returning error code 126 ( module not found ). What's really strange is that if I just run the executable from the windows explorer it works fine.
I took the usual steps to diagnose the problems:
Verify that the file existed and that the current working directory was pointed at it.
Run dependency walker and verify that it's dependencies are loading correctly. They are all loading ok except the ones this question says are ok to fail.
Experiment with loading some different DLLs at the same location in the code. Some of the simple 'stub' dlls succeed, but most of them fail.
Experiment with loading the DLLs that are failing from separate test apps - in an empty console app and a barebone MFC app, all the DLLs are loading fine!
Try to load the DLLs with LoadLibraryEx and the LOAD_LIBRARY_AS_DATAFILE flag, which does succeed but doesn't get us very far except to point out it's probably a dependency problem.
I really don't know what else to do at this point. Like I said, Office 2007 is a common thread in our problem but I don't know what kind of problems it could create. I really don't know even what steps to take next. Any ideas?
edit: I'm pretty sure the current working directory is not in the DLL path for some reason. It seems the DLLs that are failing are ones that need any other DLLs. If I turn on Loader Snaps debug output the current working directory does not appear to be in the DLL loading path. Any idea what could cause this?
edit2: The current build dumped the executable into a directory other than the working directory. For some reason, when I tried to load a DLL which then tried to load ANOTHER DLL, the current working directory is no longer searched. By putting the executable into the directory with all of the DLLs I am trying to load, the problems go away. Based on all of this, and the output by loader snaps, I am 98% sure this is some bizarre Visual Studio bug and I will simply have to work around it.
Office 2007 turns on SafeDllSearchMode in the registry.
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
With SafeDlLSearchMode, the current directory is no longer searched. To disable it, they claim you can go into regedit and set HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode to 0, but this did not work for me. Calling SetDllDirectory to the current directory DID work for me, although this only works if you are targeting XP SP1+.
The reason this caused problems in my specific app is that when we run the executable from the debugger, we keep the executable in a different directory than the current directory with all the other build files. When we run outside of Visual Studio, we first copy the executable into the directory with all of the other DLLs. The directory that the original executable is called from is ALWAYS in the search path, so if you keep your executable and your dlls together, you would never run into this problem.
Still, it's quite confusing for Microsoft to change the dll search path under us like this.
Does the DLL which fails has MSVCRT80 in dependencies? If yes, the most likely reason is that Office 2007 has overridden MSVCR80.dll
i have developed application in visual c++ 6.0,i have do exe of that application,i have done by using icnt.exe(install creator),but when i run my application exe file on other system which does't have the vc++ software it's showing dll files are missing,how could than i downloaded the dll files again it is asking other dll's files.i want run my application without installing vc++ software in windows,how can i solve it,plz help me i'm touble.
How to make Realease build? by default its debug build
thanks for reply.
As a wild guess, you have deployed the Debug build, which depends on DLLs that are not allowed to be shipped.
If that is the case, have VC6 create a Release build and deploy that.
You can verify which DLLs are required by your application with the depends.exe utility that came with Visual Studio.
Edit: The easiest way to get a release build when ready is to use the Batch Build command from the Build menu. It will let you pick among all of the known build types in the project, and choose to either build them clean (recommended) or to just bring them up to date.
It is also possible to switch the GUI to default to the Release build instead of Debug. That is the right thing to do if you actually need to run the debugger on the Release build. Note that both builds include debug symbols. The differences have more to do with which runtime libraries are linked, and certain optimizations such as making the assert() macro have no effect.