I have a strange build problem in a large solution that includes two Wix projects. Both projects give the following build error:
error LGHT0195: The Windows Installer XML variable 'WixUICostingPopupOptOut' is declared in more than one location.
The file cited for the error is Common.wxs, which I cannot find anywhere. How can I address these errors?
I suspect it has something to do with the experiment held by Bob Arnson to troubleshoot a hard-to-catch issue. In the results of that experiment (part 1 and part 2) Bob advises how to avoid build errors related to the WixUICostingPopupOptOut variable.
Related
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
I try to build SQLite v3 from source using VS2010 and run into problems which I do not know how to tackle.
This is what I have:
VS2010 pro.
using sqlite-amalgamation-3160100.zip
Microsoft article: SQLite databases
This is what I did:
Created a C++ 'Win32 Console application'.
Disabled procompiled headers.
Added preprocessor definitions: (dont do this, this is the problem!)
_HAVE_SQLITE_CONFIG_H;SQLITE_OS_WINRT;SQLITE_API=__declspec(dllexport);
(as specified by 'SQLite databases' section 3.)
Created config.h (which is empty for the moment.)
Included the source files from sqlite-amalgamation-3160100.zip in the project.
build.
I get a number of compiler errors
1> sqlite3.c
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38515): error C2065: 'MapViewOfFileFromApp' : undeclared identifier
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38515): error C2099: initializer is not a constant
1>e:\andre\ontwikkeling\sqlite\sqlite-amalgamation-3160100\sqlite3.c(38524): error C2065: 'CreateFile2' : undeclared identifier
....
... which I try to solve.
The first one leads me to the following code snipped:
#if SQLITE_OS_WINRT && (!defined(SQLITE_OMIT_WAL) || SQLITE_MAX_MMAP_SIZE>0)
{ "MapViewOfFileFromApp", (SYSCALL)MapViewOfFileFromApp, 0 },
#else
{ "MapViewOfFileFromApp", (SYSCALL)0, 0 },
#endif
Now 'MapViewOfFileFromApp' leads to MapViewOfFileFromApp function, 'Maps a view of a file mapping into the address space of a calling Windows Store app.', a valid microsoft call for which my project setup is missing the correct configuration.
I could get a workaround for this one, but other errors are depending only on SQLITE_OS_WINRT and as such not possible to work around it.
It looks like that I'm missing some configuration options but I do not know which ones. I read all of the documented compile time options but can't find out what it is that I do wrong.
I tried to find a working exaple of a VS2010 solution but came up with nothing. And of cause I checked here for similar questions! (If there is one covering this then I missed it, sorry.)
Does anybody have a suggestion on what I'm missing? I'm running out of idea's.
* edit 6 jan 2017 *
On advice of MaxFurry I followed the steps of the blog by David Cravey which does exact the same steps as I did but without declaring SQLITE_OS_WINRT;SQLITE_API=__declspec(dllexport);. Leaving these two defines out solved the problem.
Aparently I misinterpreted the advice in the Microsoft article.
Compile time problems solved.
Kind regards.
Do you have your sqlite3.dll file already built? If so just create a folder in your visual studio folder. When u want to use sqlite3 just copy the dll file to the folder of the project in visual studio u want to use it also copy the following files there sqlit3.c, sqlite3.h. When this is done open the project in your visual studio IDE. Right click on the project name, add, add existing then click on the sqlite3.h and sqlite3.c. Let me know how it goes.
When compiling a solution with many projects, if I make a compile time error in a project that many other projects use I'll get a flood of errors in the Error List window of visual studio:
Error 80 Metadata file
'C:\trunk\Projects\Libraries\K2DataBaseClient\bin\x64\Debug\CEPCortex.dll'
could not be found C:\trunk\Projects\TradeAiTeacher\CSC
These errors indicate that a project couldn't be built due to another project not being built. These types of errors cascade and don't really tell me anything useful as I know that its all due to a core project failing to build.
These errors often make it harder to find the actual error in the window.
Is there a way to tell visual studio to suppress this type of output and just show me the compile errors in cases like this to make it easy to find what actual code is broken?
Ideally it once the compile error has been fixed we can toggle this hiding off so I see all errors.
I had originally left this version agnostic but visual-studio 2013 is the version I am most concerned with.
No. The C# compiler categorically refuses to consider one error more "important" than another one. It cannot know how important an error can be, it doesn't know enough about the reason it had to produce the error. A missing reference assembly can produce a lot of errors because type definitions are missing. Of course the compiler cannot know the difference between them being undefined because of the missing assembly reference (ignore) or you mistyping a name (don't ignore).
Interpreting the Error List requires a massively parallel computing machine that's capable of high-speed correlation inference and pattern matching. With practical quantum computing still a distant future, you need to use the one that's readily available to any programmer, the one you have between your ears. Start at the top of the list. And work your way down, feeling less inclined to fix them as you progress down the list.
Never hesitate to rebuild before getting to the end of the list when you fixed a gross error. Like a missing assembly reference.
I've found the best way to work with existing the visual studio behavior is to use the advice in this link: and make the compiler stop after the first compile error.
This seems to get as close to solving my problem as you currently can.
OK, so I have the joyous task of writing a command-line build for a bunch of legacy VB6 ActiveX DLLs (so that we can integrate this into our TFS builds).
I've installed a copy of VB6 on our build server, and I'm trying, as a first step, to get one of the projects building from the command line thusly:
> VB6.EXE /make path\to\project.vbp
The result is an error dialog telling me:
Unexpected error occurred in code generator or linker. [OK] [Help]
Can anyone point me in the direction of a solution, or at least give me a hint? Thanking any respondants in advance!
Edit
It's a cross-project dependency issue. Dammit.
Sorry, I'm an idiot - turns out that the components depend on each other in various undocumented ways, and they have to be compiled in a specific order which has long since been lost.
So now I'm trawling through 30+ VB projects and documenting the dependencies :)
Thanks for those who answered anyway, sorry to waste your time.
I believe that you need to use /makedll switch - http://msdn.microsoft.com/en-us/library/aa231236(VS.60).aspx
I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...