Whenever I publish my MVC web application in VS 2010 via the One-click publish feature (I'm not doing any web.config transforms or anything fancy - yet!). The next time I come to build the app I get the following error:
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. in ...MyWebApp\obj\release\package\packagetmp
\web.config
A new copy of the web.config file is indeed created by VS2010 below the ...MyWebApp\obj\ folder so I deleted the whole obj folder and I was then able to build again.
But I shouldn't have to do that each time I publish - I must have something configured incorrectly - can anyone help please.
Thanks.
This is unfortunately a known issue with Publishing a web application to the file system. This still affects the release version (RTM) of Visual Studio 2010. It's not limited to the Beta or RC versions.
This problem "bit" me also, and I too was having to manually delete the Debug and Release folders inside the obj folder within my web site solution folder.
The real answer for an automated "workaround" can be found in this answer to the other Stack Overflow question:
Why do I randomly get a “error to use section registered as allowDefinition='MachineToApplication'” when building an MVC project?
In a nutshell, you need to delete the web.config files from either the Debug or Release folders (or both!), and that's achieved with a pre-build command (configured in the Build Events tab of the Project Properties page of your solution):
del "$(ProjectDir)\obj\Debug\Package\PackageTmp\web.config"
del "$(ProjectDir)\obj\Release\Package\PackageTmp\web.config"
Personally, I delete the entire obj folder since all those files are re-created with each build anyway.
I have just found a work around for this that has worked for me, open the .csproj for your web project and change the node under the Project\PropertyGroup node to this:
from this:
<MvcBuildViews>true</MvcBuildViews>
to this:
<MvcBuildViews>false</MvcBuildViews>
This has worked for me, hopefully it will work for you also.
Related
I have an ASP.NET MVC website project that is a few years old. When it's time to deploy an update to QA or Production, I use Web Publish to create a ZIP file and related .cmd file.
It worked fine this morning. Then I updated the project from source control. Now, when I right-click the project and select Publish..., Visual Studio 2013 hangs. After some initial research, I have tried the following:
Run as Administrator
Disable Anti-Virus (temporarily)
Clean the solution
Delete the .suo and .csproj files
Rebooted
Gave it 20 minutes to see if it unhangs
I also deleted the /Properties/PublishProfiles folder with the existing .pubxml files. When I do that, the publishing wizard opens and allows me to name a custom profile, at which point it, along with Visual Studio, hangs. No .pubxml file is written in this case.
While Visual Studio is hanging, it is not consuming any significant CPU.
What else can I try?
As it turns out, another developer inadvertently checked in a change to web.config, providing an incorrect connection string for the application's database. The web application startup code accesses the database to pre-cache some information. I'm unsure why there is no connection timeout, but that is not relevant to answering this question.
The Web Publish wizard must be causing the web application to run. Since that startup code was essentially hanging, so did the Web Publish wizard.
I am deploying asp.net web site via Octopus deploy. In TFS build definition I specified PowerShell script which pack and push Nuget package. Everything working working well except one thing: bin folder is not included in Nuget package.
When I tried to manually packing my web site into Nuget package I noticed that bin folder is included.
I supposed that something happened in TFS build process and bin folder is lost. But I cannot figure out how to solve this.
Any advice?
It sounds like you are trying to build a Website rather than a Web Application. Websites are only supported for legacy and don't get any love in the tooling. You can:
1) manually create your website layout for packaging with a post-build PowerShell script.
2) upgrade from a Website to a Web Application project and feel the love.
To upgrade you can create a new Web Application project in VS and delete all the specifics, like aspx files or other overwrites. Then drop the left over files on top of the Website, and open it in your solution. You will have two entries, one for site and one for app. Fix up the web app errors and build...
I'm getting this error when building my Multi-Device Hybrid App.
EXEC : error : EBUSY, resource busy or locked 'C:\path\to\project\bld\Debug\www\.svn\wc.db'
Suspected cause:
From what I can gather, when the Multi-Device Hybrid Apps Visual Studio extension builds the app it seems to grab all files in the project directory (except for some specific files/folders e.g. bld/bin directories and the .jsproj file) and add them to the package. That's ok, but not ideal, it really should only be grabbing the files in the VS project. The problem I'm experiencing is becuase it's grabbing my SVN .db file and adding it to the package, TortoiseSVN status cache then picks up this file and locks it - resulting in my error.
This is my specific issue, but I believe others could experience similar issues if they have any other files in the directory that they don't want included in the app bundle. I'd suggest it could be fixed by somehow setting excluded files/folders from the build or by the build script not grabbing everything, only those files included in the visual studio project. I'm not sure how to request that, so hopefully the developers will see this post...
So, my question is: Does anyone know of any way to tell the Multi-Device Hybrid Apps Visual Studio extension build process (or vs-mda\vs-cli) to ignore certain files or folders?
Or, does anyone have any suggestions as to how to make SVN and this VS extension play nice?
Unfortunately Visual Studio includes all the files under project directory except bin\bld folder. Currently only simple workaround would be to keep the files which you want to be excluded from package outside project directory. You can add the file to solution explorer by using Add --> Existing Item --> Add as link in case you want the file to appear in solution explorer but not included for build or packaging.
it seems folder with test as its name will be considered differently, and it will be excluded from package.
I'm using VS2010 connected to a local SP2010 installation, I edit the code in VS2010 (i.e. of a WebPart) and then in order to see the result on a browser I deploy the solution.
This is very annoying since it is a big project and it takes a couple of mins to deploy the solution.
I was wondering if it is possible to have the "edit -> save -> F5" approach even for SharePoint.
Thanks!
I'm gonna to integrate here the answer i get from the kind ppl and what i've actually done to solve/mitigate my slowness problem:
Installed CKSDev Visual Studio plugin from here: http://cksdev.codeplex.com/
On the SharePoint project properties tab set to 'True' the property 'Auto copy to SharePoint root', with that on each time you do save a 'visual' (ascx, aspx, js, css, ..) source file, it will be automatically copied over the SP hive without having to manually push it using the Quick Depl. option
On SharePoint project properties page (right-click, properties), add the following post build event command line:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\gacutil.exe" /i "$(TargetPath)"
iisreset
The previous commands will:
Install the project dlls into the GAC
Restart IIS in order to catch the new dlls
Now each time you do save a change in the visual or build the code it will automatically pushed to the SP installation.
For newer source files i still need to normally deploy the project.
You can do that by copying the modified file to the corresponding folder inside SharePoint Hive[14] (Or you can edit it there directly), and recycle the application pool.
Note that it this solution is only applicable to web parts, pages and xml files and it cannot be done for code files.
If you have modified your code files you have to recompile them and copy the dlls to GAC[%systemroot%\assembly] or BIN[14\bin] folder depending on your settings.
Download CKS: Development Tools Edition (aka CKSDev) from here and install into VS 2010. You will see new context menu "Quick Deploy" in solution manager which will speed up requested tasks: deploy to GAC/BIN, Recycle App Pool and more (shortcuts are accessible!). Very handy tool.
Use CKSDev, and separate your solution into smaller solutions so you can work on a subset of your projects, I would be very surprised if your webpart is dependent on every project in your master solution. If you are developing on a virtual machine without internet access also ensure that you are not waiting for timeout on your certification checks everytime you recycle the apppool (happens when you deploy). Read here for how to: http://joelblogs.co.uk/2011/09/20/certificate-revocation-list-check-and-sharepoint-2010-without-an-internet-connection/
I am going though below step during debug code.
1) if you are changes only code assembly than Build Your Project after changes code.
2) Open Assembly folder(run > assembly) and drag and drop your project's dll(will be found it out from Your Project Directory\bin\Debug).
3) open IIS (run > inetmgr) and goto Application Pools and find it out your sharepoint we-app's Pool. after selecting Application Pool (Recycle) it.
4) now come back on VS SharePoint Project.Debug > Attach to Process > w3wp.exe.
should be hit your break point.
that's it.
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "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." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.