I've been banging my head against this for a few hours.
I have a bunch of projects within a solution, with a settings.stylecop in the solution directory.
For the other projects (in the same solution) where I have StyleCop enabled (by adding the targets into the .csproj file) the settings in the solution directory are being read. For just one project this doesn't seem to happening (some of my "ignored" rules are being run).
Adding a settings.stylecop to the project directory doesn't help (nor does editing it via the VS2012 menu).
I've tried building the files using msbuild and the other projects are fine but it still gives errors.
Interestingly inside the VS IDE when I run StyleCop by clicking on the menu option it aborts with a cancelled error due to the project having more than 1000 warnings and then if change the limit in the settings.stylecop in the root then it will actually complete.
Also in VS if I run StyleCop from the menu the warnings in the error pane get doubled up, but I'm not sure if this a Resharper artefact.
So somewhere something is misconfigured (and I've scoured the .csproj to see if I can find it) but I'm a bit stumped as where to look next, anyone got any ideas? Does stylecop have any means of starting from a different settings.stylecop that can be set in a project?
In my case I was trying to suppress some of the "this." warnings and there are two options for this which was causing me to misdiagnose.
Also I suspect that resharper was confusing some things.
Related
I am an Eclipse/STS user/developer, now trying to use IntelliJ Idea (CE)
2020.2.(1,2,3)
For a project based on Gradle, how spring-integration, when I open the IDE it happens the following
Ok, let the IDE load the project ... but
From above, that is the problem, I don't want that the IDE starts automatically to build/rebuild the project. I just need, open the project and that's all.
Observation: for example in Eclipse/STS exists the option to disable Build Automatically
I did do a research in the Web and I read the following posts and questions:
How to disable automatic gradle builds?
IntelliJ IDEA “Build project automatically” apparently not working
Intellij IDEA Java classes not auto compiling on save
Sadly the dialog options were changed but ...
Therefore:
From above, seems nothing to do.
Observation: from above observe the Build project automatically option is disabled
Even with that disabled and after to restart the IDE, I must always stop manually the build process
So what is missing? or Do I need a special extra plugin to accomplish my goal?
The images that you show indicate that you are building with Gradle, but the Compiler option that you disable is relevant for building projects with Idea not with Gradle.
For the 2020.2 version, you need to do the following:
Open the Setting > Build Tools page.
Disable the "Reload changes in build scripts" option.
This way you can manually control the reload. When you change the build script, you will see a small gradle icon in the right side of the editor.
For more info, refer to the IntelliJ IDEA help > Gradle section.
https://www.jetbrains.com/help/idea/work-with-gradle-projects.html#auto_reload
There are two different things in IntelliJ's Gradle support that sometimes confused: sync and build. Your pictures demonstrate sync process (note caption on the toolwindow). Word build is kind of misleading here.
What is sync? In gradle we use Groovy to define the build procedure. Groovy is an imperative programming language, so it's hard to predict resulting dependencies graph without actually executing the script. During the sync Idea executes configuration phase of gradle build (one that builds dependency graph), and obtains configured objects from the Gradle daemon. This information is used to setup project in the IDE: modules, libraries, dependencies, which sources are test, which are prod, etc.
Actual build is not happening during sync. You can convince yourself by adding syntax error to any source file, and observe that the sync succeeds. But build will fail if you invoke it.
In answer to the original question: you can't disable automatic build, because it is not enabled.
Is it possible to disable sync in Gradle project? Short answer - no. If you need a code browser, which is not required to understand all the cross-references in the source code, IDEA is not the best choice probably.
TL;DR;
Without sync IDE does not know which files are sources, and which are not. IDEA cannot open folders. It only can open projects. Good thing is that module can contain folder. So you can do the following: File | New | Project. Select Empty project, Next, select some random folder outside the source folder you want to open, Finish.
Then add new module:
Select Java in the left panel, everything else keep default, Next, Finish. Then in new module remove existing content root, and add folder with sources as new content root
Resulting project is mostly useless. Tons of red code (at least, unresolved symbols from external libraries), no inspections, no navigation, no sense. But it might be useful in some rare situations indeed.
I have a project file that should build another solution. I tried using the MSBuild task for this, like this:
<MSBuild Projects="MySolution.sln" Properties="Configuration=$(Configuration)"/>
I tried a lot of variants, like supplying hardcoded configuration, target Rebuild and so on. Building reports an error when I pass a wrong solution name, non-existing configuration or target and so on, so it definitely loads the solution and the project files. It exits relatively fast though and produces no output. According to documentation and examples, this should work though. I also tried passing an ItemGroup for the project, including project-specific properties as suggested by examples or in MSBuild - How to build a .NET solution file (in an XML task script) from pre-written command line commands , but that does not work either. It runs without error but no output.
When passing a list of project files instead (or a single project file), it builds correctly, but the problem is that dependencies between the projects are not properly resolved. At the end, I have to supply all project files in the solution and add them to the list, which is what I want to avoid.
So, why does solution building not work, even though it should? What is wrong here?
Is this a .net project? If so you probably need to pass in a platform as well as a configuration.
<MSBuild
Projects="MySolution.sln"
Targets="build"
Properties="Configuration=$(Configuration);Platform=$(Platform)" />
If the project just contains web sites and libraries then the platform should be Any CPU if your solution just contains executables then x86 or x64 or if it's a mixture of different types of platform then you can use mixed platforms
To check what are available open the solution in Visual Studio, right click on the solution in solution explorer and select "Configuration Manager" you'll then have a drop down for "Active Solution Platforms"
I'm struggling to find a solution for this issue.
I have a solution (VS2008) that contains around 50 projects (C#).
The inter-project dependencies are added as project-reference (and not by referncing a DLL).
Also, the dependencies inside VS is set correctly in the solution settings dialog.
The problem is, when building the solution from MSBUILD (command line) on our CI server, msbuild will build the projects in what seems to be the order that they're laid out in the solution file, and not according to the dependencies.
I've found numerous references for this on the web, with no solution...
What can i do in order to build the solution correctly with msbuild from command line ?
This can be due an invalid build order inside your solution. You can change the build order without removing and re-adding the project. In Solution Explorer, right-click the solution name and select Project Build Order. You will be able to specify the build order of your projects so it should work in msbuild. This commonly happens if inside VS you have cached the DLL's during development. To verify if it works, remove all obj and bin folders before changing the build order and running the build.
We have a ASP.NET MVC with 4-5 different build configurations. Whenever we change the build configuration, we need to delete the obj folder for the web project, since we get the 'allowDefinition='MachineToApplication' error. A pain, but we managed by deleting the folder in pre/post build events.
Now I need to configure our CI to build deployment packages. This means that I cannot delete the obj folder. Every time I compile e.g. with the following msbuild parameters
/p:CreatePackageOnPublish=true /p:DeployOnBuild=true
I recieve the error:
web.config(123): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
As far as I understand, the problem is that there's multiple .config files in the project - In our case, there's not. I could really use some help to find an explanation and find a permanent (no- hack) fix.
Edit:
This question is marked as a duplicate, but the corresponding answers and cause(s) in the 2 threads, are clearly different from each other. Not sure what is intended with this tag - I've read that particular post before posting this question, as it didn't answer my question. There's multiple causes for this error message. It is 'similar', but definitely not a duplicate!
There is a similar question here on SO with some good solutions for this issue.
The problem is that building a deployment package creates a copy of the web.config in a subfolder of /obj. That will normally be be cleared out if you do a rebuild or a clean. However, if you build a deployment package in one configuration (e.g. Debug) and then switch to another confguration (e.g. Release) the obj/Debug folder is not cleared out and the web.config file there causes problems.
The quick solution is to clean all configurations and then do a (re)build. Alternatively you could delete the /obj folder in your project.
To permanently resolve the issue you can either move the intermediate output (/obj) out of your project folder or modify the project to force a clean of all configurations on rebuild.
I too was deleting the obj folder until I had a conflict with a build script which required it. Catch-22, I used the accepted answer on the following SO link to move the location of the Obj folder to C:\Temp\BUILD. You have to do it per csproj file, but it is a great solution.
Here is the link: VisualStudio: How to save the obj folder somewhere else
Note that I am using a variable for the project name.
R:\Temp\Build\Debug\$(MSBuildProjectName)
I have the above line in both debug and release sections for all my projects, including class projects. My build path is a ram drive for speed. See this SO for more info: How to access macro variables within csproj file?
I just answered a similar question here. To recap, I ran into this problem in one of our MVC projects, and it was due to having the MvcBuildViews property in the project file set to true. Setting the property to false fixed the problem.
<MvcBuildViews>false</MvcBuildViews>
I also found this answer which outlines an alternative that does not require turning off view building.
I don't know that there is an "official" fix as it just seemed to start on multiple projects of mine for no reason that I can find in Visual Studio Premium 2012 (never happened in previous versions of VS).
As a work around to automate the deletion of the obj directory as others have said, similar to an answer by user Casual in this post VisualStudio: How to save the obj folder somewhere else, where unfortunately just moving the location of the obj folder didn't always seem to work.
Instead I added a few commands under Build Events in the Pre-build event command line:
rd "$(ProjectDir)obj" /S /Q
md "$(ProjectDir)obj"
md "$(ProjectDir)obj\Debug"
md "$(ProjectDir)obj\Release"
You can change/add/remove subfolders to match your custom build configurations using the line where buildConfigName matches the name of the build configuration you are using:
md "$(ProjectDir)obj\buildConfigName"
Hope this helps!
That error indicates that you are trying to something specific to an application at an IIS tree level that isn't defined as an application. For example if you try to do app-level functions in a web.config in a virtual directory, you will get that error. You need to find the path you are deploying to and make sure that it is defined in IIS as an application vs a folder or vdir.
Cleaning the solution (Right click Solution in VS, clean), worked for me.
I had the same error but with a deployed page.. Then realized my webserver's clock was set back to 2010 for some reason. set it to the correct date fix my problem
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
Althoug the problem is explained and solved in one way in the accepted answer, I wanted to show a solution which can be better for other cases. This solution has been included in some version of VS, but I can only say that I had the problem in VS 2013 Update 5. (See the "Beware" below, it could be fixed in this version, but not working only in my particular case).
I borrowed the soltuion from Error: allowDefinition='MachineToApplication' beyond application level on Visual Studio Connect.
The solution consist in including these lines to the web application project (.csproj file) which handle the deletion of the offedning intermediate files (which wans't a solution for the accepted answer, as he needed those intermediate files):
<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="#(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="#(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
Beware: for some reason, probably because I included it myself in the project, my build target for building the views was named "BuildViews", instead of "MvcBuildViews", so I had to modify the BeforeTargets attribute accordingly.
This is not necessarily the exact same issue, and to be honest, probably down to pure lack of knowledge on my part, however I had this same error when:
I set up a standard asp.net new project actually just used for HTML5 stuff so nothing other than the usual project structure
I then (not thinking perhaps!) added a new WCF REST project (which actually was just another base asp.net project using very good examples from http://www.codeproject.com/Articles/128478/Consuming-WCF-REST-Services-Using-jQuery-AJAX-Call?fid=1597004&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=26#xx0xx and http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
The problem was I added the WCF REST project (#2) as a SUB-DIRECTORY of the main project (#1) and then tried to build! even if I cleaned the project of course.. I also made both projects use IISexpress because I thought there was an issue using the same port or something.
Of course the build process saw the web.config from #1 and then a sub-dir with another web.config #2..
I realise this probably should be a very basic understood gotcha and it has caught me out a while ago, however sometimes it's the simplest of mistakes that are a real pain!
Might help others... who perhaps haven't had their morning coffee..
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/ (all files)
You should have to open demo from vs... not demo1.
I have a somewhat a similar problem, i had the main config as Copy Always so it copied the config to the bin directory. When i republished the main project, i got the MachineToApplication error. So my solution was to just change the config to Do Not Copy and remove the extra configuration in the bin folder.
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.