I have a solution in Visual Studio 2005(professional Edition) which in turn has 8 projects.I am facing a problem that even after i set the Command Arguments in the Project settings of the relevant project, it doesnt accept those command line arguments and it shows argc = 1, inspite of me giving more than 1 command arguments. Tried making the settings of this Solution similar to a working solution, but no success.
Any pointers?
-Ajit.
Hmm.. Are you sure the specified project is set as the start project (right click > set as startup project) ??
Oh, and obviously you need to be in the correct configuration mode ^_^
(Notice it can be changed to debug | build | all configurations )
Are you sure you are setting the command arguments on the same configuration (Debug|Release) you are debugging? As far as I remember command arguments are per configuration.
Related
I have successfully built OpenDDS 3.13.2 from source. Here is my environment:
Windows 10
Visual Studio 2017 (re-targeted Solution to SDK 10.0.17763.0)
Tried all Configuration/Platform combinations
I successfully used the configure script from the VS command prompt, built everything by opening the generated solution in the same command prompt, and finally ran the Messenger example (publisher and subscriber), and even configured it to use RTPS successfully.
However, when I try to create my own IDL and use the tao_idl, it crashes. Here's my test (using the proper environment from setenv.cmd):
> tao_idl (no args)
IDL: No input files
Second test:
> tao_idl Test.idl (crashes)
I get no error message, and am unable to locate logs or any indication of what went wrong. The same thing happens when I used opendds_idl.
What is the best approach to debug this, and/or are there pre-built binaries available for the IDL compiler(s) (both TAO and OpenDDS)?
After about a day of troubleshooting, I have determined a solution. Despite being able to call tao_idl and opendds_idl yourself, you should basically never do it. There are a good amount of command-line arguments needed to get both to work, and if they're not present, each exe will crash without the proper reasoning why.
I will add my steps below to create a new basic two-exe pub/sub project using OpenDDS:
Create your own IDL file.
Starting with the DCPS Messenger example, modify the .mpc file, replacing Messenger.idl with your IDL file name.
Create a new file called <your project>.mwc, and add the following contents:
workspace {
// the -relative and -include cmdlines make it so this workspace
// does not have to be in the $DDS_ROOT directory tree.
// tell MPC to substitute our DDS_ROOT environment variables for relative paths
cmdline += -relative DDS_ROOT=$DDS_ROOT
// tell the projects where to find the DDS base projects (*.mpb)
cmdline += -include $DDS_ROOT/MPC/config
}
Open a new VS command-line terminal and run $DDS_ROOT/setenv.cmd, or open a regular terminal if you have those environment variables set via Windows settings.
Navigate to your project directory and call: mwc.pl -type vs2017, replacing "vs2017" as needed for your build tool/IDE.
Open up the generated solution, and retarget it as necessary for your Windows SDK version.
Build the <your project>_IDL project first. If you notice in the output window, it is invoking the tao_idl and opendds_idl commands automatically. You can view the .vcxproj files to see the full command-line arguments that were the original problem.
Modify the publisher.cpp, subscriber.cpp, and DataReaderListenerImpl.cpp files to match your new IDL. Run the example as usual and ta-da!
For completeness, the full commands for both tao_idl and opendds_idl are as follows:
> opendds_idl -Sa -St "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>TypeSupport.idl"
I've just downloaded the Visual Studio 2017 Community.
Once I try to compile any program (even the simplest "Hello World") with any configuration (release/debug, x86/x64, empty project/windows console application), I get the following error:
Microsoft.CppCommon.targets(381,5): error MSB6006: error MSB6006: "CL.exe" exited with code -1073741515 (This error means STATUS_DLL_NOT_FOUND, I know it's been asked before, but I don't know how to check what DLLs are missed).
Microsoft.CppCommon.targets(381):
<CL Condition="'%(ClCompile.PrecompiledHeader)' != 'Create' and
'%(ClCompile.ExcludedFromBuild)'!='true' and
'%(ClCompile.CompilerIteration)' == '' and #(ClCompile) != ''"
Do you know how to check what DLLs are missing?
I'm new but i hope I'll answer quite properly. To reach the actual error code you need to change it to hex. Yours is
C0000135
. As far as I know it's file damage related,so you're right about dll missing. In older visuals the way to know it was via command line.
Ran msbuild.exe <my.sln> /t:<mytargetproject> from a VS2010 command prompt, where <my.sln> is your solution name and <mytargetproject> is the project you are trying to build. For e.g. msbuild.exe helloworld.sln /t:mainproj.
That is a cite from different post in stackoverflow.
Error Code -1073741515 When Using EDITBIN
Hope it will be easier for you to resolve problem with this. Can't help more as I don't use VS neither Windows. Good luck!
I have this warning that never goes away and I don't know how to get it fixed:
Warning Name cannot begin with the '$' character, hexadecimal value 0x24.
.Android C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets 1668 Build
After enabling detailed verbosity, it points to this section of the Xamarin.Android.Common.targets file:
<Target Name="_GenerateJavaStubs" DependsOnTargets="_SetLatestTargetFrameworkVersion;_PrepareAssemblies;$(_AfterPrepareAssemblies)" Inputs="$(MSBuildAllProjects);#(_ResolvedAssemblies);$(_AndroidManifestAbs);$(_AndroidBuildPropertiesCache)" Outputs="$(IntermediateOutputPath)android\AndroidManifest.xml;$(_AcwMapFile);$(_AndroidTypeMappingJavaToManaged);$(_AndroidTypeMappingManagedToJava)">
<GenerateJavaStubs ResolvedAssemblies="#(_ResolvedAssemblies)" ResolvedUserAssemblies="#(_ResolvedUserAssemblies)" ManifestTemplate="$(_AndroidManifestAbs)" MergedManifestDocuments="#(ExtractedManifestDocuments)" Debug="$(AndroidIncludeDebugSymbols)"
NeedsInternet="$(AndroidNeedsInternetPermission)" AndroidSdkPlatform="$(_AndroidApiLevel)" AndroidSdkDir="$(_AndroidSdkDirectory)" PackageName="$(_AndroidPackage)" ManifestPlaceholders="$(AndroidManifestPlaceholders)" OutputDirectory="$(IntermediateOutputPath)android"
MergedAndroidManifestOutput="$(IntermediateOutputPath)android\AndroidManifest.xml" UseSharedRuntime="$(AndroidUseSharedRuntime)" EmbedAssemblies="$(EmbedAssembliesIntoApk)" ResourceDirectory="$(MonoAndroidResDirIntermediate)" BundledWearApplicationName="$(BundledWearApplicationPackageName)"
PackageNamingPolicy="$(AndroidPackageNamingPolicy)" ApplicationJavaClass="$(AndroidApplicationJavaClass)" AcwMapFile="$(_AcwMapFile)">
</GenerateJavaStubs>
<ConvertResourcesCases ResourceDirectories="$(MonoAndroidResDirIntermediate)" AcwMapFile="$(_AcwMapFile)" />
</Target>
I have no idea if I need to modify this or if one of my files is causing the issue. I double checked, none of my files actually start with a $.
Any ideas?
Thank you.
Seems to be a Xamarin bug, at least in some circumstances. Logged Github issues here and here with repro steps and a sample project.
Try this:
Open Windows Task Manager -> Go to the Details Tab
End all MSBuild.exe tasks you may find
Go to your project folder, delete Bin & Obj folders (SHIFT+DEL)
Close Visual Studio completely
Open Visual Studio again, open your solution, rebuild.
OR this:
Open Project settings
Go to Android Manifest
Make sure your Version number doesn't have dots or commas
Looking through the diagnostic output of Visual Studio, I could see a lot of '\$' occurrences, most of them related to Google Play.
For me, the solution was that I had forgotten to install Google Play in the SDK Manager (under Extras).
For me, a Visual Studio 2017 update did the trick.
Now it is only a warning anymore.
Name cannot begin with the '$' character, hexadecimal value 0x24.
VS 17 update from 15.4.4 to 15.7.4 was done.
I have experienced this error on Android, and what I have done to make it works is: "Version Number" should be a number and it should not contain the dot.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging
I am trying to migrate one of projects earlier in VS2008 to VS2010. On building I get the following error
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(317,7): error MSB4094: "hdxBinding.idl;hdxBlinking.idl;HDXCommandObject.idl;hdxds.idl;HSCProcessStatus.idl;HSCSelectableWindow.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
On clicking this error, it takes me to the line Source ="#(Midl)" inside C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets file
A Code Snippet in Microsoft.CppCommon.targets file:
<ItemGroup>
<Midl Condition="'#(Midl)' != ''">
<MinimalRebuildFromTracking Condition="'$(BuildType)' != 'Build' or '$(ForceRebuild)' == 'true'">false</MinimalRebuildFromTracking>
</Midl>
</ItemGroup>
<PropertyGroup>
<MidlToolArchitecture Condition="'$(MidlToolArchitecture)' == ''">$(DefaultToolArchitecture)</MidlToolArchitecture>
</PropertyGroup>
<MIDL
Condition ="'%(Midl.ExcludedFromBuild)'!='true'"
Source ="#(Midl)"
AdditionalIncludeDirectories ="%(Midl.AdditionalIncludeDirectories)"
AdditionalOptions ="%(Midl.AdditionalOptions)"
ApplicationConfigurationMode ="%(Midl.ApplicationConfigurationMode)"
ClientStubFile ="%(Midl.ClientStubFile)"
CPreprocessOptions ="%(Midl.CPreprocessOptions)"
DefaultCharType ="%(Midl.DefaultCharType)"
DllDataFileName ="%(Midl.DllDataFileName)"
EnableErrorChecks ="%(Midl.EnableErrorChecks)"
ErrorCheckAllocations ="%(Midl.ErrorCheckAllocations)"
ErrorCheckBounds ="%(Midl.ErrorCheckBounds)"
ErrorCheckEnumRange ="%(Midl.ErrorCheckEnumRange)"
ErrorCheckRefPointers ="%(Midl.ErrorCheckRefPointers)"
ErrorCheckStubData ="%(Midl.ErrorCheckStubData)"
ExcludedInputPaths ="$(ExcludePath)"
GenerateClientFiles ="%(Midl.GenerateClientFiles)"
GenerateServerFiles ="%(Midl.GenerateServerFiles)"
GenerateStublessProxies ="%(Midl.GenerateStublessProxies)"
GenerateTypeLibrary ="%(Midl.GenerateTypeLibrary)"
HeaderFileName ="%(Midl.HeaderFileName)"
IgnoreStandardIncludePath ="%(Midl.IgnoreStandardIncludePath)"
InterfaceIdentifierFileName ="%(Midl.InterfaceIdentifierFileName)"
LocaleID ="%(Midl.LocaleID)"
MkTypLibCompatible ="%(Midl.MkTypLibCompatible)"
OutputDirectory ="%(Midl.OutputDirectory)"
PreprocessorDefinitions ="%(Midl.PreprocessorDefinitions)"
ProxyFileName ="%(Midl.ProxyFileName)"
RedirectOutputAndErrors ="%(Midl.RedirectOutputAndErrors)"
ServerStubFile ="%(Midl.ServerStubFile)"
StructMemberAlignment ="%(Midl.StructMemberAlignment)"
SuppressCompilerWarnings ="%(Midl.SuppressCompilerWarnings)"
SuppressStartupBanner ="%(Midl.SuppressStartupBanner)"
TargetEnvironment ="%(Midl.TargetEnvironment)"
TypeLibFormat ="%(Midl.TypeLibFormat)"
TypeLibraryName ="%(Midl.TypeLibraryName)"
UndefinePreprocessorDefinitions ="%(Midl.UndefinePreprocessorDefinitions)"
ValidateAllParameters ="%(Midl.ValidateAllParameters)"
WarnAsError ="%(Midl.WarnAsError)"
WarningLevel ="%(Midl.WarningLevel)"
TrackerLogDirectory ="%(Midl.TrackerLogDirectory)"
MinimalRebuildFromTracking ="%(Midl.MinimalRebuildFromTracking)"
ToolArchitecture ="$(MidlToolArchitecture)"
TrackerFrameworkPath ="$(MidlTrackerFrameworkPath)"
TrackerSdkPath ="$(MidlTrackerSdkPath)"
TLogReadFiles ="#(MIDLTLogReadFiles)"
TLogWriteFiles ="#(MIDLTLogWriteFiles)"
ToolExe ="$(MIDLToolExe)"
ToolPath ="$(MIDLToolPath)"
TrackFileAccess ="$(TrackFileAccess)"
AcceptableNonZeroExitCodes ="%(Midl.AcceptableNonZeroExitCodes)"
YieldDuringToolExecution ="$(MidlYieldDuringToolExecution)"
>
</MIDL>
Can somebody please tell me whats going wrong here. This is driving me crazy!!!!!!
Got a similar error today on a project that I am converting to VS2010. I don't have a good solution to the problem yet, but I have a workaround. In my case, the project contained 2 idl files. Call them A.idl and B.idl. A.idl is the main idl for the project. It includes B.Idl. The error I received was:
error MSB4094: "A.idl;B.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
It seems that the build system searched for all idl files in the project and made a single call to the MIDL compiler with all of them even though that was bound to fail. I don't know why VS2010 does that and earlier version didn't (or maybe earlier versions of MIDL could handle multiple inputs).
The workaround: grab the MIDL arguments off of MIDL Command Line page of the project's properties. Then run MIDL by hand in a VS2010 Command Prompt window using those args. In my case, since A.idl includes B.idl, I only needed to run one MIDL command:
MIDL options-copied-from-project-properties A.IDL
It looks like you have multiple idl files in your project (hdxBinding.idl, hdxBlinking.idl, etc.). So the same trick might work for you.
Good luck
I ran into this issue trying to build the DataMonitor example from the TMG SDK with Visual Studio 2010. The problem from what I can tell is the MIDL > Output settings in the project - the Header File, IID File, Proxy File, and Type Library were set to "DataMonitor...", which was forcing those settings to be applied to all included IDL files (and not just the project's generated one).
Changing those settings to use %(Filename) instead and the project built fine.
When there are multiple IDL files in the project I converted from VS 2008 to VS 2010, I got this error. Since one IDL I had was included in the other. I disabled building of the included IDL file and it resolved this error.
These errors prop up when migrating to VS2010 as the .idl file properties are not migrated by VS2010 migrator. I got a similar error and resolved this by manually adding these parameters from to VS2010. Once done you will be able to get rid of these build errors.
I run into the same problem as well. The fix was (very confusing) remove empty in the vcxproj file. I run out of time and have not got to the bottom of why it helps - defining not empty HeaderFileName fixes the problem as well, other empty elements do not cause this problem (e.g. DllDataFileName).
If you want to reproduce bug or process of my investigation just create hello world and add two idl files. It should work. However if you add ItemGroupDefinition with Midl.HeaderFileName it should start failing. One wild guess is that it has something to do with batching of tasks (working example calls MIDL task for each file separately).