Quantcast
Channel: Daffodil for Visual Studio - Native Multitargeting Platform Toolsets
Viewing all 116 articles
Browse latest View live
↧

Commented Issue: Problems when I build in vs2010/vs2012 for vs2003 [1177]

February 19, 2014, 5:41 pm
$
0
0
There is something very troublesome.
When I compile VS2003 project in vs2010/vs2012,there‘s a big problems, it's looks like this:
I modified a '.h' file, and build my project, some .cpp files entirely unrelated were compiled again, It's not the most interesting.
if I modifed a '.cpp’ file, those .cpp entirely unrelated were compiled again too, it me crazy...
I'm thinking is enybody encountered a similar situation, and how did you solved the problem?
Comments: ** Comment from web user: thexujie **

Yes, it says "Skipping...". But, what I found was these files were rebuilding actually. The resons are as follows.
1.It tooks me a long time for "Skipping..." as it says when the .cpp file is large/complex enough. In my working project, it took me about 10mins to build when I modified a simple .cpp file as mentioned above.
2.You can take a look at the corresponding .obj file of the .cpp file in your intermediate directory, those .obj files of the "been skipped", the create-time of those .obj files are the time you build, so, the .obj files are created again.

And if I disable the producing of the PDB file in settings, it performs normal.

↧
Search

Edited Issue: Problems when I build in vs2010/vs2012 for vs2003 [1177]

February 19, 2014, 8:00 pm
$
0
0
There is something very troublesome.
When I compile VS2003 project in vs2010/vs2012,there‘s a big problems, it's looks like this:
I modified a '.h' file, and build my project, some .cpp files entirely unrelated were compiled again, It's not the most interesting.
if I modifed a '.cpp’ file, those .cpp entirely unrelated were compiled again too, it me crazy...
I'm thinking is enybody encountered a similar situation, and how did you solved the problem?
Comments: ** Comment from web user: owenwengerd **

I can't explain what happens under the hood and why it behaves this way, but it's apparent that the .obj files are processed and modified as part of the PDB building process. I don't think they are being compiled, at least not on the same level as a normal compile. In any case, it appears to me to be working as intended, so I am closing this issue as resolved. Thanks for taking the time to provide this feedback.

↧
↧

Closed Issue: Problems when I build in vs2010/vs2012 for vs2003 [1177]

March 7, 2014, 7:58 pm
$
0
0
There is something very troublesome.
When I compile VS2003 project in vs2010/vs2012,there‘s a big problems, it's looks like this:
I modified a '.h' file, and build my project, some .cpp files entirely unrelated were compiled again, It's not the most interesting.
if I modifed a '.cpp’ file, those .cpp entirely unrelated were compiled again too, it me crazy...
I'm thinking is enybody encountered a similar situation, and how did you solved the problem?
Comments: Working as designed.
↧

New Post: Visual Studio 2010 C++ cannot see classes instances in debug window but can see native types ..Why?

April 13, 2014, 6:46 am
$
0
0
This was posted on Stack overflow but I've had no luck
(http://stackoverflow.com/questions/23036879/visual-studio-2010-c-cannot-see-classes-instances-in-debug-window-but-can-see).

There is a similar but not exactly same question here but proved not useful see.

https://daffodil.codeplex.com/discussions/391875


I have VS2005, VS2008, and VS2010 installed on my Win7 development machine.
My application has a C# front end which makes calls into my C++ dll.
I am building my dll which uses a collection of third party dll's some of which were
built using Visual Studio 2005. I am using Daffodil to do ensure my dll is also built (from within Visual studio 2010) using the Visual Studio 2005 compiler and linker.

The problem is that within my dll I can see local variables of native C++ types (longs doubles char * etc) but the debugger refuses to show any of my C++ classes or STL types (e.g. std::string). I don't think it is an issue with the PDB for my dll as I can clearly set breakpoints and see native c++ types (longs, doubles, char * etc) but it just refuses to show any classes either in the watch window or when I hover over the variable. At first I thought it might be an issue with the microsoft stl implementations so I created a simple local class that only contains intergers and NO complex classes/stl member instances. I instantiated it, set a break point and I still cannot see this simple class. The simple class looks like this 
class LocalClass
{
    public:
        LocalClass();       
        int         myInt;
};
So in effect this is nothing more than a glorified int!!

I instantiate it simply by doing the following (from within another class method) 
LocalClass *cl = new LocalClass();
When I add the this pointer and cl variable to my watch window it gives me this 
this    CXX0017: Error: symbol "this" not found 
cl  CXX0017: Error: symbol "cl" not found
What I believe is happening is that the debugger just cannot figure out where the "this" pointer is and hence it goes bezerk and gives up.

So just to verify that I indeed did natively compile using visual studio 2005 I stepped into the new method sure enough it is calling into the version 8 runtime that ships with 2005 (strangley enough I can see all the complex types in .dbgheap.c and afxmem.cpp.

Here is the stack when allocating the above class. 
msvcr80d.dll!_heap_alloc_dbg(unsigned int nSize=8, int nBlockUse=1, co
msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=8, int nhFlag=1, int nB
msvcr80d.dll!_malloc_dbg(unsigned int nSize=8, int nBlockUse=1, const 
mfc80d.dll!operator new(unsigned int nSize=8)  Line 347 + 0x10 bytes    
mydll.dll!CApplicationData::CApplicationData()  Line 88 + 0x7
It is drivng me nuts and I really don't want to trace every line to the debug window!
↧

New Post: Visual Studio 2010 C++ cannot see classes instances in debug window but can see native types ..Why?

April 20, 2014, 3:13 pm
$
0
0
I don't really have any ideas offhand other than the two links you already dismissed. I've been meaning to create a test project to see if I can reproduce your problem, but I just have not had time. It would help if you can create and attach a standalone solution containing minimal projects that demonstrate the problem. If you do, I'll be happy to investigate.
↧
↧

New Post: No Symbols have been loaded

April 24, 2014, 3:24 am
$
0
0
I am using VS2010 and target Visual C++ 6. All compiles great , but when I try and debug, breakpoints are hollow and exclamation says Breakpoints will not currently be hit, No symbols have been loaded for this document. I can see a pdb file which is the same as the exe, and I have even tried telling it to add only this pdb in Options/Debugging/Symbols but still no luck. Any one any ideas?

Thanks
↧

New Post: No Symbols have been loaded

April 24, 2014, 3:31 am
$
0
0
I'm n windows 7 64 bit by the way I also get this below which would say the symbols for my exe (HMInt,exe) are loaded but obviously it isnt happy with the Windows 64 bit symbols

'HMInt.exe': Loaded 'D:\QNX630\WorkingFolder\963909401 PRISMIC PMS HMI 2 - Network-VERSION_2_0_17\Src\Debug\HMInt.exe', Symbols loaded.
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\version.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\nsi.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\MFC42D.DLL', Symbols loaded.
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\MSVCRTD.DLL', Symbols loaded.
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\MFCO42D.DLL', Symbols loaded.
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\MSVCP60D.DLL', Symbols loaded.
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\msimg32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\uxtheme.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18201_none_ec80f00e8593ece5\comctl32.dll', Cannot find or open the PDB file
'HMInt.exe': Loaded 'C:\Windows\SysWOW64\dwmapi.dll', Cannot find or open the PDB file
↧

New Post: No Symbols have been loaded

April 24, 2014, 8:54 pm
$
0
0
Some things to check:

1) Make sure you're starting the freshly built executable, and not a different one.
2) Make sure C/C++\General\Debug Information Format is set to one of the Program Database options.
3) Make sure Linker\Debugging\Generate Debug Info is set to Yes.
4) Make sure the source code file you're placing the breakpoint in is actually the one included in the project.
↧
Search

New Post: No Symbols have been loaded

April 25, 2014, 12:46 am
$
0
0
Ok, its sort of working now I changed the Debug Information Format is set to one of the Program Database options, but now I reach the breakpoint no problem, bt when I try and step I get

Unhandled exception at 0x00495433 in Ntmmi.exe: 0xC0000005: Access violation reading location 0xcae506db.

What is the difference with the database options? Is there anything to stop this new problem? Thanks for your help
↧
↧

New Post: No Symbols have been loaded

April 25, 2014, 3:43 pm
$
0
0
I don't know what else to add beyond the 4 items I've already mentioned. You might try creating a new simple project from scratch to see if everything works there. If it does, you can start comparing settings. If the simple project exhibits the same behavior, you might start looking for Visual Studio patches. I know VS 6 had dozens of patches, not all of which got rolled into a service pack (i.e. you have to download and apply them piecemeal).
↧

Reviewed: Daffodil MSI (Multi-Language) (May 17, 2014)

May 17, 2014, 2:37 am
$
0
0
Rated 5 Stars (out of 5) - Really helpful, works very well!! Works with VS2013
↧

Updated Wiki: Home

June 20, 2014, 8:04 pm
$
0
0
Project Description
Daffodil provides native multi-targeting platform toolsets for Visual Studio 2010 C++ developers who need to target older versions of Visual Studio.

To use these platform toolsets, you must have the targeted version of Visual Studio installed. Currently supported platforms are:
- Visual Studio 2005 (VC 8)
- Visual Studio 2003 (VC 7.1)
- Visual Studio 2002 (VC 7)
- Visual Studio 6 (VC 6)

Visual Studio 2012
Daffodil works fine in VS 2012 and VS 2013 as long as VS 2010 is also installed.
↧

Updated Wiki: Home

June 20, 2014, 8:04 pm
$
0
0
Project Description
Daffodil provides native multi-targeting platform toolsets for Visual Studio 2010 C++ developers who need to target older versions of Visual Studio.

To use these platform toolsets, you must have the targeted version of Visual Studio installed. Currently supported platforms are:
- Visual Studio 2005 (VC 8)
- Visual Studio 2003 (VC 7.1)
- Visual Studio 2002 (VC 7)
- Visual Studio 6 (VC 6)

Visual Studio 2012/2013
Daffodil works fine in VS 2012 and VS 2013 as long as VS 2010 is also installed.
↧
↧

New Post: v60 toolset and TFS 2013 build

July 25, 2014, 7:51 pm
$
0
0
I'm getting this error from a TFS 2013 build agent running on Windows Server 2012 R2:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v60\Microsoft.Cpp.Win32.v60.targets (93): The "CLA" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v60\Daffodil.CPPTasks.Win32.v60.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v60\Daffodil.CPPTasks.Win32.v60.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

The solution will build from within VS2013 but not when the TFS build service builds it. I'm thinking it could have something to do with MSBuild ToolsVersion. Any ideas? Thanks.
↧

New Post: v60 toolset and TFS 2013 build

July 25, 2014, 8:49 pm
$
0
0
It sounds to me like your .NET security policy is preventing the assembly from loading for whatever account your TFS build service is running under.
↧
Search

New Post: v60 toolset and TFS 2013 build

July 27, 2014, 10:05 am
$
0
0
Setting "MSBuild platform" in the build definition to "X86" instead of "Auto" fixed the problem.
↧

New Post: VisualStudio vs SDK requirement

September 4, 2014, 1:42 am
$
0
0
Hello,
I'm currently looking into targetting the VS80 toolset from VS2010 (for native code), because operations would like to drop support for VS2005 on their deployed workstations (which I can understand). However for a couple of reasons (Legacy systems, ...) the code base can not be ported to the new VS2010 compiler (at least not yet...). (next step would be VS2013)

I managed to add the vs80 toolset myself (I didn't knew this wonderfull daffodil yet).
But was hoping it would be possible to remove the need of a VS2005-install.
Instead of this I would prefer to modify Microsoft.Cpp.Win32.v80.props
to refer to compiler/linker/platformSDK folder etc. which was deployed through xcopy or by intallation of the "Windows SDK"

Would this be possible? Any possible issues?
↧
↧

New Post: VisualStudio vs SDK requirement

September 4, 2014, 8:28 am
$
0
0
The purpose of a platform toolset is to use the build tools from that toolset, so yes, they must be installed. Since the build tools are dependent on CRT/MFC SDK files specific for that version of the tools, those specific SDK files must also be installed. Changing .props files to point to a newer platform SDK is no different than just selecting a newer platform toolset, and it does not resolve the dependencies on CRT/MFC SDK files. You can of course update your code to use the VS 2010 toolset, but that's the only practical way to eliminate the need for the VS 2005 build tools.
↧

New Post: VisualStudio vs SDK requirement

September 4, 2014, 2:34 pm
$
0
0
Maybe I threw into much info...

I understand I still need all the CRT/MFC and other platform headers,libs,compiler etc...

I sure need the VS2005 build tools, currently they are on the system because VS2005 is installed.
I was hoping I can target the vs80 toolset by using a build/develop-machine with:
-only VS2010 and an older Windows Platform SDK installed (which also contains all build tools of VS2005), but not the VS2005 IDE itself.
-or even better: only VS2010 installed and an xcopy version of CRT/MFC-headers and libs/compiler/linker/... (and thus have a 'portable'-like set of the VS2005 buildtools, in the end we just need to call cl.exe and link.exe with correct parameters and some envVars set... Correct?)
↧

New Post: VisualStudio vs SDK requirement

September 4, 2014, 7:31 pm
$
0
0
The VS 2005 build tools are only available as part of VS 2005 proper. I'm sure it would be possible to separate them into an xcopy-able toolchain merged with the older platform SDK, but I doubt this would pass legal muster. In any case, it would be a lot of work in exchange for relatively little savings over just deploying the full VS 2005 and using Daffodil.
↧
Viewing all 116 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>