Nant is complaining about a duplicate target, and as far as I can tell there is no duplicate. Is there some way to get nant to tell me which buildfiles it has open or is trying to open and where these tasks are so I can debug this?
Although I haven't found a reasonable debugging solution, I did find that this was related to updating nant. An old buildscript that worked began to break on a "duplicate target" error. This was because a taskfile was included by 2 other taskfiles already included in the project. nant found two different paths to the same task, and thought it was two distinct tasks and consequently flipped.
Related
I moved a web application I am working on from one machine to another. It is built using .Net MVC and Entity Framework but when I execute the Update-Database command so that the database is updated, I get this error:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "NameofMigration.resources" was correctly embedded or linked into assembly "NameofProject" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Does anyone know how to fix this error?
I had a similar issue when the resx part of the migration was not included in the project file when a fellow developer checked the project in (probably due to a merge issue). You may find that the resx file is there but greyed out. If it's there, try right clicking the "NameofMigration.resx" file and selecting "include in project". If it's not there, you better go find it on the other machine and add it to the project :-)
I think the issue (one issue) is that the .resx file is added as "dependent upon" (nested under) the .cs file, and the way the build engine works, "dependent upon" changes the name that an embedded resource is saved with (something like, it changes from being based on the filename to being based on the type name; I've dealt with this in other scenarios but can't remember for sure).
This leads to problems when using SDK .csproj files, for some reason (I guess that by default SDK .csproj does not change the resource name in this situation, but the migrations system expects it to).
As someone else had posted, SDK .csproj can use the following tag to change the embedded resource naming scheme for "dependent upon" resources, which then allows the migrations system to find the embedded resource:
<EmbeddedResourceUseDependentUponConvention>
true
</EmbeddedResourceUseDependentUponConvention>
This should go in a <PropertyGroup> of your SDK .csproj file.
For VS 2017, the solution is as follows:
Go to the project file, and for all of the migrations, apply the following format:
<Compile Include="Migrations\201804251606403_emailsWithEffort.cs" />
<Compile Include="Migrations\201804251606403_emailsWithEffort.Designer.cs">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</Compile>
<EmbeddedResource Include="Migrations\201804251606403_emailsWithEffort.resx">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</EmbeddedResource>
I guess that the problem is when changing version(s) of Visual Studio, old format of describing dependencies stays, and the Visual Studio 2017 can not interpret it correctly.
Hence, applying the format as described above (change your format to this), you can make the Visual Studio get the idea of where it's resources are.
Slightly different situation, where I created a new environment, and database, and received the above error message.
For my fix, I had to right-click on the migration files (initial and resx) and set property to embedded as resource. Update-database command ran fine afterward.
I encountered the same issue (VS 2017) and none of the solutions provided here worked. I fixed the problem by cleaning the solution and manually deleting the bin folder and then building it again.
If anybody wants to look into the source or compiler to know why this is happening; I don't feel like it right now. After an hour of tinkering, my resolution is odd.
Granted, I shouldn't have done this in the first place, but for quick code I temporarily added classes into the same file as my generated DbMigration 201906212110305_initial.cs. The mere existence of those temporary classes in the same file caused this error. As soon as I moved them to their own file (which I was going to do all along anyway) the runtime error vanished.
Unloading and then reloading migration file worked for me!
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.
I am losing my hair in my attempts to get RestKit to build and work. I get the dreaded "Lexical or Preprocessor issue: RestKit/RestKit.h file not found" message. I use Xcode 4.2 & my project is for iOS.
Earlier, I had debug mode working perfectly with RestKit 0.9.0. Then I ran into issues while trying to archive. After reading this forum and attempting some solutions, I decided to upgrade to 0.10.0 with hopes that it will solve the issue.
Now, my project is not even building in debug mode and I get the same RestKit/RestKit.h file not found error.
I have this under Header search path: "$(BUILT_PRODUCTS_DIR)/../../Headers". Can you please suggest (for 0.10.0 version):
1) Where should the physical location of RestKit be? (It may not matter, but which one worked for you - with hopes that I can mirror your setting)
2) I tried to point my header search path to "/Developer/Library/RestKit-RestKit-69adee9/" and later to "/Developer/Library/RestKit-RestKit-69adee9/Build"
Throughly confused and frustrated..
EDIT1: After several hours, I gave up. Nuked my project. Created a fresh project. Re-created the files (copy paste from prev project). Now "RestKit not found" error is gone! But now, I am getting this other error:
Undefined symbols for architecture i386:
"_OBJC_CLASS_$_RKObjectMapping", referenced from:
objc-class-ref in myclassname1.o
"_OBJC_CLASS_$_RKObjectManager", referenced from:
objc-class-ref in myclassname2.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked & made sure that I did NOT add RestKit.framework... I've no idea why the clang error is happening now
EDIT2: The libRestKit.a was red. It is OK according to https://github.com/RestKit/RestKit/wiki/Installation-Troubleshooting Just for the heck of it, I removed all the linked dependencies. Removed the "Other linker flags". Closed & reopened Xcode. Put them all back. That error is gone. Maybe I missed a framework which resulted in clang error. But it is highly unlikely for I checked & double checked. It works now.
It builds & archives on debug mode. I haven't tried the distribution mode yet.
EDIT3: Apple approved my app in the first go & it is live! I still do not know what caused the issue here. Nuking an existing project & creating a new one & copying over the old files (& periodically checking if build goes through) cannot be a solution. So I am leaving this question open.
I think I can shed some light on this.
When you upgrade to 0.10.0, you change your header search paths to "$(BUILT_PRODUCTS_DIR)/../../Headers", right?
The install guide only says to do this for the project settings. However in many cases, mine included, you'll need to also update them for the target settings as well.
The target settings will still have the old header search paths, and for whatever reason decide not to inherit from the project settings.
Mind you - its a total hack - but it got my project running.
Assuming that you've already followed the installation steps from the RestKit Github
https://github.com/RestKit/RestKit/blob/master/README.md#quick-start-aka-tldr
In the RestKit target, goto Build Phases. Under the Copy Headers dropdown, move all of the header files from "Project" to "Public".
Clean, Build, Run.
Solution I found was not to copy and past the "$(BUILT_PRODUCTS_DIR)/../../Headers" to your target's Header Search Paths.
After five hours I deleted the copy and pasted " and manually typed them in and it worked.
I recently played around with upgrading from RestKit 0.9.3 to 0.10.0 and had the same thing. Did you delete the RestKit/build directory? This contains a copy of the .h files and is created as part of the build process when building 0.9.x. Doing Product -> Clean doesn't seem to delete these files. 0.10.0 doesn't seem to create this build directory. I suspect that your build errors are due to those files still being picked up.
Also, to answer your question fully, I keep RestKit files in:
(project dir)/Frameworks/RestKit
This is a git submodule so it contains a clone of the RestKit git repo at a particular revision.
And the header search path is:
$(BUILT_PRODUCTS_DIR)/../../Headers
The header search path for 0.9.3 was:
$(SOURCE_ROOT)/RestKit/Build
I found this guide helpful (maybe this is what you are already following): https://github.com/RestKit/RestKit/wiki/Installing-RestKit-in-Xcode-4.x
and note the section about only having libRestKit.a in the project for the latest RestKit versions where earlier versions had all of:
libRestKitNetwork.a
libRestKitObjectMapping.a
libRestKitSupport.a
libRestKitJSONParserJSONKit.a
libRestKitXMLParserLibxml.a
libRestKitCoreData.a
If you have all of these, delete them from your project.
Been fighting with the same issue for the past few hours. What finally worked for me (and I'm not saying this is a definite fix, but at least it's something to try).
Delete RestKit from your Project
Close your project
Move the RestKit folder next to your main xcodeproject
Open the RestKit project and build it
Close the RestKit project
Open your project, and re-import the RestKit project into your xcodeproject
Fix the Dependencies and Linkings in the target settings
Add the "$(BUILT_PRODUCTS_DIR)/../../Headers" search path to BOTH the project settings and the target settings. (it only worked for me when they were listed in both).
This last step might be all that's necessary to fix it, but since I too was pulling my hair out over this, I tried a lot of different solutions and didn't want to assume that this last step was the sole reason it fixed itself.
(and my setup is XCode 4.3.2 and OS X 10.7.3)
After spending 2 days on this same error and navigating to every possibile google result I finally got it!
It's not due to Derived Data settings, those are fine already in XCode 4.3.2.
The problem is that you are doing a #import "RKObjectMapping.h" or some other include.
Instead use #class RKObjectMapping or if you really nead the .h use <RestKit/RKObjectMapping.h>
I went with #class since I just need to compile...
Hope this help!
Had this problem too. It would build and run just fine on simulator, but would not archive. Here's where I went wrong...
I did this:
#import "RestKit.h"
Rather than the correct way:
#import <RestKit/RestKit.h>
I had the exact same error today. All our code is in a github repo and the restkit folder is ignored so none of the restkit files were in there. Now, when xcode opens the project and finds stuff missing, it assumes all hell broke loose. So, deleted the folder, re cloned it and then grabbed a fresh copy of the restkit and threw it in there and voila, everything worked.
I found that I need to manually build the RestKit target for the header files to be copied into the build directory. Apparently the master project build does not reliably run the subproject build?
So, my steps for fixing this issue:
Select the RestKit run target
Build
Make sure the header search path was set on all target (apparently on project itself is not enough)
Build main project
Had a very similar problem. It turned out to be I had accidentally added the build setting to "User Header Search Paths" rather than "Header Search Paths".
My solution:
When adding "$(BUILT_PRODUCTS_DIR)/../../Headers" to
Targets -> Build Settings -> Search Paths -> Header Search paths,
the value was not set.
Instead the value has have been set up to User Header Search Paths.
So you double click to Header Search Paths, some pane with lines appear, you click + down left, paste that string there, click somewhere else to dismiss the window and... nothing.
The Header Search Paths didnt get updated but User Header Search Path did.
?!!!
So you click on the disclosure button on Header Search Paths.
Click + sign right of the attribute and add the value...
Here's a common mistake that'll make you want to slap yourself after you fix it.
Yes, you definitely do want to add "$(BUILT_PRODUCTS_DIR)/../../Headers" to your target's Header Search Paths, but don't forget to include the quotes!
I'm talking about the quotes that are before $(BUILT and after _DIR)/../../Headers
If your build configuration has a space in the name (e.g. mine is 'Ad Hoc') and you've just added $(BUILT_PRODUCTS_DIR)/../../Headers without the leading and trailing quotes, you may end up getting the "Lexical or Preprocessor issue: RestKit/RestKit.h file not found" problem.
This is a problem that I don't think has enough answers for this problem, because if you have this problem it feels like there is nothing to be done! After trying all of the proposed solutions (none of them worked). I finally found the problem
The problem was that one of my folders had a space in it. Don't use spaces in your source folder names!
Used to be : (/Xcode projects/basicRestkit etc...) -- lots of pain and suffering
changed to : (/projects/basicRestkit) -- lots of rejoicing
This caused the header search paths not to work, and therefore not to find the files. There may very well be a way to use alter the header search paths to find your files even with spaces.
This might not help you, but it very well could. Good luck.
For me only these steps works. Check here Hope this will help.
I build my project(include subproject Three20) successfully using xcode GUI,but when I use xcodebuild,it failed with this below:
/Users/***/MyProject/Classes/ComposeSMSViewController.h:14:9: fatal error: 'Three20/Three20.h' file not found [1] #import <Three20/Three20.h> 1 error generated.
my Header Search Paths are $(BUILT_PRODUCTS_DIR)/../three20 and $(BUILT_PRODUCTS_DIR)/../../three20 and Classes/Three20/Build/Products/three20
That works on GUI building but failed on xcodebuild.
How can I solve this? Thanks
I think you should restart three20's install , it need several steps and make sure it's without mistake. Best regards. It may help you: http://three20.info/article/2011-03-10-Xcode4-Support
If it still doesn´t work (and an error like "Three20.h file not found" is shown), try setting "Skip Install" to "Yes" for all of the Three20 dependencies and projects in your app (except your main project): graphically . This onle creates an .ipa for your project, but not for your three20 projects.
I resolved this issue today by accident. I tried all the solutions I found online and it didn't work. I was pretty confident that the problem was within xcode because the app built fine on my boss's machine. Turns out my scheme name didn't match my target name. This was a result of duplicating a target, which automatically named my scheme to "myapp copy". When I matched the scheme name to the target name, everything worked fine and the three20.h file was found. Hope this helps anyone with similar circumstances.
Product-> Manage Schemes... and rename the file
Well we are facing a strange problem with JetBrains TeamCity induced unit tests on our main project where tests from few library projects are failing regularly. Apparently, it's not reading the config file (coming from app.config and nicely stored in project -> bin -> debug -> projectName.dll.config).
Hints or tips on what could be the real issue would be highly appreciated.
I've got the same problem and wasted a couple of hours to figure out what the problem is.
In our case, the NUnit plugin was configured to run the tests from:
**\*Tests.dll
Though this sounds to be OK, it has turned out that this pattern will not only match to the MyTests.dll in the bin\Debug folder but also to the obj\Debug\MyTests.dll. The obj folder is used internally for the compilation and does not contain the config file.
Finally the solution was to change the plugin configuration to
**\bin\Debug\*Tests.dll
Actually we use a system variable for the build configuration so we did not have the "Debug" hard-coded. Using bin* might be also dangerous when the workspace is also used for Debug/Release builds and you don't have a full cleanup specified.
You might wonder why I did not realize the test count mismatch (actually it was doubled, because they were running once from bin and once from obj), but this is typical: while everything is green, you don't care about the count. When we have introduced the first test depending on the config, we had only one failure (because the one from bin was passing), so the duplication was not outstanding.
In addition to Gaspar Nagy's accepted answer, check to see if your project has multiple test dlls and one of them is referencing another.
This causes the referenced dll to be run twice, and the copy that was in the other dll's folder to not have the proper app.config entries. The proper fix is to remove any and all references from the other test project.
TeamCity (v6.5.4) has its own NUnit Test Runner and there seems to be an inconsistency between it and the NUnit GUI test runner (2.5.10). The NUnit GUI Test Runner follows the long standing convention of expecting the configuration file name to be of the format .config. You can see this in NUnit by looking at Project -> Edit...
TeamCity on the other hand is looking for an app.config.
Your options are to either:
Set the NUnit GUI to point to app.config and include the resultant
nunit project in your source control.
Have both an app.config and a .config - syncing both
manualy.
Add a step to your build process to copy .config to
app.config (or vice versa).
I had similar woes
This may help; additionally we had issues where this still would not work - we ended up copying the relevant config sections into the highest level config file. (i.e. if it was a web app copy it into the Web.Config) - fairly kludgy but we had wasted a few days on the issue
I learned recently that app.config files are not read for a class library... Maybe this link could help :)
app.config for a class library
If you need a config file for your "unit" tests then you are doing it wrong. Proper unit testing never needs configuration or access to the database, file system etc. You should change your testing strategy.
Good point to start is mark your tests that need configuration with the[Category("Integration")] annotation and set the Teamcity test runner to ignore this category. Then you should focus on refactoring these test.