In short we have teamcity set up with a build project that contains an Umbraco web site.
The build step is pretty basic and setup as a Visual Studio runner type. Everything works and builds fine.
The problem is the build process is VERY slow, and after some digging I found out its because it spends times logging hundreds of the exact same warning (also teamcity never uses the full computer resources available, odd).
Here is one such warning logged:
[AspNetCompiler] d:\TeamCity\buildAgent\work\213321ddb3a6b826\eSignaturUmbracoMVC\umbraco\Dialogs\insertMacro.aspx(99, 0): warning CS0618: 'umbraco.ui' is obsolete: 'Use the ILocalizedTextService instead which is the ApplicationContext.Services'
Its only Umbracos pages making that error. So I thought I could suppress that warning using "/p:nowarn=0618" as a command line parameter in the build step. But it doesnt work. I have tried just about any method I could find but the warning is still not suppressed.
Any suggestions? I am pretty lost here...
How to suppress specific MSBuild warning
msbuild.exe MySolution.sln /t:Rebuild /p:WarningLevel=0 /p:Configuration=Release
^^^^^^^^^^^^^^^^^
Warning
Level Meaning
-------- -------------------------------------------
0 Turns off emission of all warning messages.
1 Displays severe warning messages
2 Displays level 1 warnings plus certain, less-severe warnings, such
as warnings about hiding class members
3 Displays level 2 warnings plus certain, less-severe warnings, such
as warnings about expressions that always evaluate to true or false
4 (the default) Displays all level 3 warnings plus informational warnings
Related
I am building VC++ project using msbuild in batch file. I get about 1500 of same type of warnings (C4554). When running on a build server, i want that warning not be displayed on console window but they be logged in log file.
I have tried couple of methods like
call %MSBuildToolsPathVS%/msbuild %SolFilePath% /p:configuration=debug;WarningLevel=0;Platform=x64^
/flp:LogFile=%MSBuildLogPath%;Verbosity=normal^
or even this
call %MSBuildToolsPathVS%/msbuild %SolFilePath% /p:configuration=debug;WarningLevel=0;Platform=x64^
/clp:Summary^
/flp:LogFile=%MSBuildLogPath%;Verbosity=normal^
or
call %MSBuildToolsPathVS%/msbuild %SolFilePath% /p:configuration=debug;Platform=x64;WarningLevel=0;RunCodeAnalysis=false^
/clp:Summary^
/flp:LogFile=%MSBuildLogPath%;Verbosity=normal^
still displays the warning on console.
call %MSBuildToolsPathVS%/msbuild %SolFilePath% /p:configuration=debug;Platform=x64^
/clp:ErrorsOnly^
/flp:LogFile=%MSBuildLogPath%;Verbosity=normal^
/t:rebuild
causes log file to display warnings correctly but the console now hides the warnings but it also dosn't show usual steps of what configuration is being build, the target that is built etc, which is the information I want.
Any solutions?
sedy
I recently turned on stricter warnings for a project, and Xcode started throwing warnings on some of Apple's classes. I'm not sure if this is an Apple bug, or if I'm doing something wrong. I'm using Xcode 6.1.1 on Yosemite.
TL;DR: adding some strict warning flags to your project starts throwing warnings in various XC*Test*.h headers. The issue is intermittent, but the steps below have reproduced the issue on multiple computers.
Steps to reproduce:
Create a new Xcode project via File → New → Project.
Choose iOS → Application → Single View Application.
For Product Name, type MyApp. Choose Objective-C and Universal. Save the project.
Build the project with CommandB. Run the tests with CommandU. Observe that they both finish with no errors or warnings.
Click on the Project to go to the Project Settings.
Click on the blue MyApp Project (as opposed to MyApp or MyAppTests targets).
Click on the Build Settings tab.
Search for Other Warning Flags.
Enter the following string for the Other Warning Flags for the app:
-Weverything -Wno-objc-missing-property-synthesis -Wno-objc-property-synthesis -Wno-direct-ivar-access -Wno-assign-enum -Wno-float-equal -Wno-sign-compare -Wno-switch-enum -Wno-gnu -Wnewline-eof
Build the app again. You should see three or four warnings about treating #import as #import, which is expected given the warnings you just enabled.
Clean the project with CommandShiftK
Build again. You may see extra warnings. If not, then you need to…
Delete the DerivedData folder, at least for this project. It is located at /Library/Developer/Xcode/DerivedData/MyApp-*, where * is some random identifier string. You may also need to delete /Library/Developer/Xcode/DerivedData/ModuleCache.
Clean and build again. And again. It may take a few times. Eventually...
You will see code and documentation warnings on XCAbstractTest.h, XCTestCase.h, and XCTestSuite.h. Screenshot:
As you can see, these warnings would be quite valid on my own code, but this is Apple’s framework code. Is there any way to stop these weirdly intermittent warnings from appearing? Or is it an Apple bug that the file gets warnings at all? I’m leaning Apple bug, because plenty of other Apple headers use #import instead of #import, and none of them is throwing warnings.
Update: I filed a radar: http://www.openradar.me/20038246
Update 2: I was able to glean some more information that may be helpful:
The issue appears to be at least partly related to where Derived Data is stored. See this screen recording, courtesy of Sam Marshall for details: http://cl.samdmarshall.com/a4Hy
Note that, when I reproduce the same steps as in Sam's video on my computer, I am not able to get rid of the extra warnings. They always come back. Possible differences between my and Sam's setups:
Sam is on Xcode 6.1, while I am on 6.1.1.
Sam is on Mavericks, while I am on Yosemite (10.10.2).
When I build in Xcode 6.3b2, I get an additional warning about "building module 'UIKit'". See screenshot: http://cl.ly/a3sK
Update 4: Radar was closed as a duplicate of an issue.
Update 5: I have a workaround, which is to disable the problem warnings on the Tests target only. Here’s a partial diff. Xcode won’t add the $(inherited) automatically, so you’ll have to add it yourself.
+ WARNING_CFLAGS = (
+ "$(inherited)",
+ "-Wno-documentation-unknown-command",
+ "-Wno-auto-import",
+ "-Wno-incomplete-module",
+ );
I get errors from both build and website precompile on App Harbor that seem to originate from multiple versions of the C# dynamic assemblies. They both start with warnings that look like:
2>CSC : warning CS1685: The predefined type 'System.Runtime.CompilerServices.CallSite' is defined in multiple assemblies in the global alias; using definition from 'd:\temp\qb3ydb5o.xoq\input\packages\IronJS.Core.0.2.0.1\lib\net40\Microsoft.Scripting.Core.dll' [D:\temp\qb3ydb5o.xoq\input\...csproj]
The build passes, but website precompile has these warnings but fails:
(0): error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.InvokeMember'
d:\temp\qb3ydb5o.xoq\output\_PublishedWebsites\...cshtml(4): error CS1969: One or more types required to compile a dynamic expression cannot be found. Are you missing a reference?
I wonder if it has anything to do with how IronJS is packaged? Can someone help me troubleshoot this error?
I fixed this by removing references to Microsoft.Scripting.Core and Microsoft.Scripting.ExtensionAttribute. These were added by the IronJS NuGet package. I still have AppHarbor build errors, but those are because AppHarbor isn't doing a clean build (different problem).
Edit: I submitted an issue with IronJS: https://github.com/fholm/IronJS/issues/92
I have a C++ Builder application I'm porting from C++ Builder 6 to XE on Windows XP.
A number of 3rd party controls are in use as well.
I'm compiling with Dynamic RTL = False
If I compile without run time packages I get the subject error message:
[ILINK32 Error] Error: Unresolved external 'SHCreateItemFromParsingName' referenced from C:\PROGRAM FILES\EMBARCADERO\RAD STUDIO\8.0\LIB\WIN32\RELEASE\VCL.LIB|Dialogs
If I compile with run time packages the error goes away.
Googling around reveals the SHCreateItemFromParsingName has to do with common control dialogs one can invoke with WinAPI calls.
All 3rd party controls I use work in a new/separate project; thus this problem does appear to be a simple #define or something.... (not sure)
I can not find anything in my project source that would cause this. I do have an TOpenDialog and a TSaveDialog in my project that replaced an older TMC components of the same names (TntOpenDialog, TntSaveDialog) that were used in CBuilder6 to give Unicode support for the same. Converted to the ones that ship with the VCL has not resolved this problem.
There is an Embarcadero thread on this but that person appear to solve by creating #define's to build their app for WinXP and new compatibility. Under XE, I set the C++ Compiler option to target Windows XP and newer and that did not work either.
Tried adding:
"#define WINVER 0x0502"
"#define _WIN32_WINNT 0x0502"
per MSDN link here:
http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx
to no avail.
Other than the Open/SaveDialog components, anyone have any advise or seen this before?
OK, spent two days on this and as soon as I post it here, I found the solution.
Under the Build Configuration (right click | edit )
Under Application there is a check box "Enable runtime themes" that was unchecked.
Checked it and problem now gone.
I'm getting a strange error when trying to compile a solution that is using StructureMap on Team Build.
When I try to compile the solution locally on Visual Studio it works fine, but when trying to queue a new build in Team Build I get the following error:
Overload resolution failed because no accessible 'Use' can be called with these arguments:
The line of code that gets this error is the second one:
ForSingletonOf(Of ISessionFactory)().Use(NHibernateSessionFactory.SessionFactory)
Me.For(Of ISession)().lifecycleIs(New HybridLifecycle()).Use(Function(x) x.GetInstance(Of ISessionFactory)().OpenSession())
It's a standard registration for the NHibernate session, so I don't really get why this error pops up.
Thanks in advance for the clues.
Make sure you have the correct version of NHibernate on the build server, and that your hint paths are all appropriately set in your project file. We haven't had this specific issue (as we're not using NHibernate), but we've had weird issues like that being related to version mismatches of "infrastructure" DLLs between local and build.