I am facing this annoying error
"Fatal error rc1015: cannot open include file wx/msw/rcdefs.h".
I am on Windows 10 and visual studio 12. Anybody has an idea about this.
Thanks
You have almost surely (because you don't say that you did it, when this would really be the first thing to check) forgot to specify the correct include paths for your resource compiler. Just add $(WXWIN)/include to the list of directories searched by it.
If you are using Visual Studio, Go to the
Project -> Properties -> Resources -> General -> Additional Include Directories
and add the include path of wxwidget (wxwidgets path/include) to it.
Related
I have a solution with 3 Websites and 1 Web API project. When I build the solution there is no issue but when I publish the Web API project to file folder, I get a lot of errors and the publish fails. One of the error is:
Error CS0006 Metadata file
'D:\Projects\MyAppName\Code\MyAppName\BusinessObjects\bin\Release\BusinessObjects.dll'
could not be found.
Other issues are similar to:
Error CS0246 The type or namespace name 'Amazon' could not be found
(are you missing a using directive or an assembly reference?)
I have checked in the project. The referenced DLL(Amazon) is available and this issue doesn't occur when I build the solution.
What could be the issue? I have also checked if there is any missing file(checking for yellow exclamation icon in front of file name) but I couldn't find one.
VS2017: Solution builds but publish fails
(According to the error messages, they are all common errors. we could not give the most direct correct answer for this issue, we can only give you some troubleshootings. In order to avoid losing contact in the round-trip comments, I post those troubleshootings as answer instead of comments.).
You can try:
Clean solution then rebuild it.
Go to Solution Explorer. Right click on Solution. Go to Properties. Go to Configuration Manager. Check if the checkboxes under Build are checked or not. If any or all of them are unchecked, then check them and try build the solution again.
Remove the project reference and then adding it back in again, and check if all those missing dll file exists in the bin folder.
Delete bin/obj folder, build again and try to restart Visual Studio.
in IntelliJ (2016.2 and previous) we have our Groovy classes marked red with the error "class already exists".
I think we can exclude that the cause is the stub-generation, as this is deactivated.
Probably it's caused in our constellation: We have included our compiled groovy (and java) classes in a jar that is registered as dependency.
Dependency MyProduct.jar contains com.mycompany.MyGroovyClass
Our source contains com.mycompany.MyGroovyClass
The error disappears if the dependency is registered with Test-Scope, in all other scopes the error appears.
However, in our structure we kinda have to include the compiled classes in a compile scope, as we want to avoid that each developer needs to compile all classes (I know about the compile in background ability, but we have a constellation that prevents this from working).
We have no errors in com.mycompany.MyJavaClass which exists as well in source and in MyProduct.jar.
Any ideas on how we can solve this?
We've been suffering the same issue, it seems to be that IntelliJ registers the Java class, but also the Groovy class, and because of that it is showing that message (BTW, we are using a Maven Project).
So we ended up by going to the target folder -> right click -> Mark Directory As -> Excluded. Then, this setting will be saved on the IML file, and it won't happen again.
Hope it works for your as well!
Cheers
I'm using gmavenplus-plugin:1.5
After marking target/generated-sources/generated-sources/main as "Excluded", The error disappeared. I even did "invalidate cache and restart", It persists the setting. This is great. Intellij 2017.1.5
We have two ways to fix this issue
Exclude Stub Directory
target folder -> generated-sources -> groovy-stubs -> Right click main folder -> Mark Directory As -> Excluded
Remove generateStubs goal from gmaven plugin
Remove <goal>generateStubs</goal> from gmavenplus plugin
Make sure you Mark the src folder as Sources Root and do the same for the test folder
Then delete the target folder (most likely it's marked in yellow) and don't worry it won't delete any code from your project
If the issue persist, proceed to go to File -> Invalidate Cache/Restart
Build error is occurring since using Visual Studio 2015. When building in Visual Studio 2015 this is occurring rarely. When building in TeamCity this occurs very often.
[Error in Visual Studio 2015]
Error extracting public key from file 'CompanyName.snk': The process cannot access the file 'C:\Users\UserName\AppData\Local\Temp\tmp2FF6.tmp' because it is being used by another process. CompanyName.Project.DAL D:\Projecten\CompanyName\Repository\Source\Components\CompanyName.Project.DAL\vbc
http://i.stack.imgur.com/hKbbe.png
[Error in TeamCity]
CSC error CS7027: Error signing output with public key from file 'CompanyName.snk' -- The process cannot access the file 'C:\BuildAgents\Gamma\temp\buildTmp\tmpD91D.tmp' because it is being used by another process.
http://i.stack.imgur.com/rbgHx.png
I know it's been a while since this was asked but as I use SO for my own reference and I had this problem too I wanted to share my solution.
.snk files are for signing a project. You might need to make a new one.
Right click on your project, select properties.
Click on Signing.
Click the checkbox beside "Sign the assembly".
On the dropdown labelled "Choose a strong name key file" click new.
Fill in the dialog box as you wish noting particularly the Key file name. When you press ok, this will generate a new .snk file.
Save the project and rebuild.
This will use the new .snk in your project and will resolve the
error.
Hope this helps.
Try to clean up the temp folder that is used by the build.
I have seen different types of problems when the temp folder has lots of files.
Some of the tools are using GetTempFileName and they will get errors when temp has a lots of files
The GetTempFileName method will raise an IOException if it is used to create more than 65535 files without deleting previous temporary files.
This is probably an instance of this issue with Roslyn compiler. The workaround would be adding
<UseSharedCompilation>False</UseSharedCompilation>
under any <PropertyGroup> node in .csproj file.
It started for me when I moved the Resharper Cache to System Temp. When I moved it back to the Solution folder, the problem went away, and I could build again.
I just had the same problem. In Visual Studio 2015, I fixed it using the following steps:
Go to Tools > Options
From the Options dialog, select "Projects and Solutions > Build and Run"
Set the "maximum number of parallel project builds" to 1
+1 to #stukselbax for getting me on the right track
Also got help from this link
I used '/m:1' as an msbuild argument, and 'SignPublic' property to true in the csproj file.
Just had this issue today in visual Studio 2022- I was messing with the csproj file and ended up having the wrong filepath to the snk file. I fixed it by changing the filepath to be correct.
Right-click on the project -> unload (so that you can edit the csproj file)
Under <PropertyGroup> check the <AssemblyOriginatorKeyFile> tag
My code was:<SignAssembly>true</SignAssembly> <AssemblyOriginatorKeyFile>../NAMEHERE.snk</AssemblyOriginatorKeyFile> NAMEHERE was specific to my project, yours will vary. Look at your snk file. The ../ in front will vary, check the filepath of your snk file. If you caused this error by messing with your csproj file, like I did, then the correct answer is what the filepath was before you changed it. :)
Right-click on the project -> reload
This question has evolved over the past several weeks to cover more general issues with xcode4 (and upgrading projects form older xcodes).
However many of the issues can be solved by following the same set of instructions.
If you have any of the following issues, try the methods in the accepted answer:
Xcode 4 fails to archive an App
Xcode 4 creates an unusable archive
Xcode 4 does not create an .ipa
Xcode 4 fails to compile due to preprocessor errors
Xcode 4 cannot find headers
Xcode 4's code complete is not working
Project dependancies won't compile
Adding a dependancy causes any of the above issues
Original Question
Title: "lexical or preprocessor issue file not found" in Xcode 4
I have a project in Xcode 4 that will build fine and run on the device and simulator but when trying to Archive it errors when looking for headers files associated with a static library:
In file included from /Volumes/Development/Path/LBProject/LBProject/LBProject-Prefix.pch:15:
In file included from /Volumes/Development/Path/LBProject/LBFDefines.h:23:
In file included from /Volumes/Development/Path/LBProject/Classes/LBProjectAppDelegate.h:11:
In file included from /Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDirectoryManager.h:10:
/Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDataModel.h:11:9: fatal error: 'Merchant.h' file not found [1]
#import "Merchant.h"
^
1 error generated.
Xcode gives the error
lexical or preprocessor issue file not found
Much Googling has show many people are having this issue but no solution. Anyone got a fix or even a clue.
Update: The user header search paths are set to ${BUILT_PRODUCTS_DIR} in all configurations. It builds fine using any configuration except when archiving.
Update 2: Merchant.h is a Core Data class that is auto-generated and therefore inside .xcdatamodeld package, however the headers are all copied to the public headers directory when the library is built.
NB: The steps below will solve 90% of your Xcode archive issues
however, from the comments it is suggested you try quitting Xcode
first. This may save you hours of setting tweaking.
Check the "user header paths" are correct (Add "" to paths for spaces, both in your project and dependencies)
Set "Always search user paths" to YES
Create a group call "Indexing headers" in your project and drag the headers to this group, DO NOT add to any targets when prompted. This includes any headers inside your .xcdatamodeld, you'll need to right-click and view package contents to find them.
For all dependencies set "Skip Install" build setting to "Yes"
Moving any "Public" headers in Build Phases to "Project"
Set the Build Setting "Installation Directory" on your Target to $(LOCAL_APPS_DIR)
Change the target build setting "scan all source files for includes" to YES. (link)
With newer versions of Xcode (> 4.2) you might want to read this question related to workspaces.
Manually delete the project.xcworkspace files form all referenced projects
I had the same problem in XCode 4: "Lexical or preprocessor issue MyFile.h not found". However, MyFile.m was not a static library, just a standard class. And MyFile.m and MyFile.h were included properly and indexed in the project.
So ... I quit XCode and the Simulator, then restarted them and the problem disappeared.
I found that the problem went away when I changed the target build setting "scan all source files for includes" from no to yes.
I was able to resolve this issue without any changes to any of the build settings by simply copying the .h files into the Project's directory in the finder. I did NOT add them to the project at all. Just having them in the project's filesystem directory seemed to be enough to allow Xcode's implicit linking to work properly. More details here.
I had a weird issue like this. Changing "Scan all resource files..." to Yes didn't help. I took a look at the Framework Search Paths and noticed that I had
$(inherited)
"$(SRCROOT)"
"$(SRCROOT)/my/correct/path"
It seemed right but was still failing. I then tried rearranging the order of 2 & 3 and all of a sudden it built fine. So not sure why that was the hickup, but wanted to add it to the list of things to try in case it helps someone else.
My solution was to change my
#import "HeaderFile.h"
to
#import <FrameworkName/HeaderFile.h>
and everything started working again.
What was unusual was that it had stopped working suddenly after building
a few times.
The problem resolved itself when I set
Build Settings->Project->Search Paths to Yes
I had the same — 2 targets in my project (Project and ProjectTest of GHUnit). When my scheme was set up to Project, the import of <GHUnitIOS/GHUnit.h> was problem of “lexical or preprocessor issue file not found”. But when I set as a scheme ProjectTest, everything was OK. So, I have added GHUnitIOS.framework in Project too.
Looks like your header search paths are incorrect not configured properly in your build settings for the active scheme. Verify them and update your question with the current setting.
I'm having similar issues on the simulator but not the device and my header search path fields are empty (Seems to be default). But changing Workspaces seems to have solved the issue. Maybe you could try creating a new Workspace, add your project to it and see if that helps. Now I'm investigating why.
I was getting this "file not found" error for one particular .h file in my project. I resolved the issue by removing that .h file from the project (selecting "Remove references") and re-adding it.
Adding on more variant: I had two instances of foo.m in the Compile Source build phase, which some how caused "Header not found" for foo.h.
Another chance:
In workspace project: watch in the Target for section Build Phases. As many manuals says you need to have a Copy Files Build Phase to copy all your headers to another place, as iOS Framework cannot contain header files to be shared (this is my case).
Choose for those Copy Files as Destination option "Products Directory". Or another directory of your like where the headers will reside.
That worked for me. Probably the build for Archive (or Release) directory is very different than expected in build for Debug .
Also check in your workspace settings your build directory.
XD
For me, this issue occurred after I added new files to the project; a blank .m and .h derived from NSObject. Here's how I resolved it:
Closed and restarted xCode
Deleted the two new files via XCode
Recompiled successfully
I then Re-added them afterward and it also worked.
Definitely a bug in xCode...
For our VB.NET websites we use SVN for Source Control and CruiseControl.NET for continuous integration.
To use the SVN build number in the compilation by CruiseControl.NET we need to use Web Deployment Projects. We then replace in the configuration file the Version field with this variable from SVN Labeller
$(CCNetLabel)
This works great but my problem is that this variable causes warnings in Visual Studio for the solution. I'm working to remove all warnings and am left with just these two:
Warning 1 The version string specified for 'AssemblyFileVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
Warning 1 The version string specified for 'AssemblyVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
I have searched for ways to disable certain warnings but they all reference Windows projects not web site/deployment projects which do not contain a Compile tab.
I found information on using #pragma warning( disable : 1000 ) but it appears this is for C++ only and not VB.
It's not a show-stopper but is annoying the hell out of me this lazy Friday afternoon, any help would be appreciated - if reputation sharing was working yet I'd offer someone 20 of my rep for a workable solution :) at least....
It is possible to ignore errors, it is just in a weird place for vb.net.
Open the .vbproj file with notepad or an equivalent and find the <NoWarn> tag and add the id of the error there.
in a default 2008 winforms, I have these warnings already ignored.
<NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
If you used Nant in your build script you could just have it re-write the version prior to compile, and you wouldn't see the warning when you are working on your local machines.
Had a very similar situation with an old VB web project, and we did not want to add the #pragma blocks all over the code calls. For some reason, adding the lines to the <NoWarn> fields did not make Visual Studio builds ignore/suppress the warnings.
However, I found a different approach. By adding this in the .vbproj file after the <NoWarn></NoWarn> area ignored the obsolete warnings in VS 2017:
<DisabledWarnings>612;618</DisabledWarnings>
Common MSBuild project properties
Description of configuration setting:
DisabledWarnings Suppresses the specified warnings. Only the numeric
part of the warning identifier must be specified. Multiple warnings
are separated by semicolons. This parameter corresponds to the /nowarn
switch of the vbc.exe compiler.