I've a solution with several .dll projects, an Asp.NET MVC3 Razor project and an Cloud project.
If I try to compile the solution with the Cloud project loaded, VS2010 gets stuck in "Buil started".
I have to forcefully close VS2010 killing the process and restart. Then the compiling works good once, the next time it will get stuck again.
If I unload the project and set the mvc project as start-up, everything works (but azure of course).
What could be the problem?
Cheers.
Was it by any chance an ASP.NET MVC project to which you added a CloudService project later on or did you start off with a CloudService from the very beginning?
I was in the former situation and I had no end of problems, like not being able to open property pages or deploying the application. It's not quite your issue, but the following article might help:
http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/
As I say, my problems started because I actually added an Azure project to an existing ASP.NET MVC solution and there were some unnecessary settings left over in the web.csproj file.
All I had to do was open web.csproj in notepad and remove all occurrences of the <PlatformTarget> element.
My MVC prjoject was x86 and of course Azure works on x64 only. Even though I had the platform target set up as AnyCPU somehow Azure couldn't quite get along with it.
Maybe cleaning up your project files helps as well.
Related
Visual Studio is ignoring my breakpoints. I don't know if it makes a difference but this is happening in Web API. I know it's passing over my code because I can put Console.WriteLine('FOO'); in and it shows up. But it passes over my breakpoints like they aren't even there. I added System.Diagnostics.Debugger.Break(); and that gives me this dialog even though I opened Visual Studio as an administrator.
I'm starting the Web API project directly. That is, I'm not starting a project that uses Web API and therefore need to right click Solution > Startup Projects and set Web API to start. The project is in debug mode. I've cleaned my solution, restarted IIS, and closed and reopened Visual Studio.
Also, I can open other projects, like an ASP.NET MVC app, and the breakpoints work fine there. It's just Web API. Any idea what I am doing wrong?
Restart your computer.
I don't know what the exact cause was but after trying everything else I restarted and now it works.
Also, I had to run it from another project. If I debug the Web API project it doesn't hit the breakpoints but if I debug from the Web UI project (Web API is part of that solution) it works.
edit
And actually that only worked like one time. I ended up including Web API in startup projects and also copying the dll and pdb to c:\mySymbols on each build via post build commands copy c:\path\the.dll c:\mySmbols\the.dll and then going to debug > options > debugging > symbols and adding the path to c:\mySymbols to the list.
edit
Another thing is I was trying to use a custom request validator via
<httpRuntime requestValidationMode="4.5" executionTimeout="300" maxRequestLength="51200" requestValidationType="MyProj.App_Code.CustomRequestValidator" />
and that definitely breaks it. So I had to take that out too (at least until I figure this problem out).
I'm not sure which, if any of these things did the trick but it is working now.
I am having some problems deploying an app I created to IIS on Amazon AWS. I have basically taken a sabbatical from development and haven't deployed an app in over a year.
The app has been transferred across fine and runs to the point of causing errors and displaying that frameworks are missing etc. I solved this in the past by:
Changing what version of .NET was being used on the server
Including all DLLs when the programme actually transferred (not what it does by default)
For the life of me, I cannot remember how to include all DLLs when deploying the programme so those can be relied on instead of the system's frameworks. Can someone please remind me?
You can do Right Click on Project and select Add Deployable Dependencies from the context menu
As of MVC4, all necessary assemblies to run an MVC application are
automatically added to the bin directory, and any MVC4 application is
bin-deployable (means you can run it in a server without explicitly
installing MVC) . For this reason, the Include Deployable Assemblies
dialog has been removed from Visual Studio 2012
More here: https://stackoverflow.com/a/10441585/1241400
Are you by any chance talking about Bin Deploying MVC? It's kind of a pain to do, considering you need to remember to make sure those dependencies are in your bin folder any time you either move the application around, put it on a new server, etc.
What errors is your displaying? I think you'd probably be better off resolving those, if possible. Windows has gotten much friendlier with installing updates in the past few years.
I recently upgraded from VS 2003 where I was working on a ASP.NET 2.0 website to VS 2010 where I have migrated to ASP.NET 4.0. So far it has been a big headache to get my site compiling with the new version. One problem was that my aspx.cs pages could not find the shared code libraries in my project. I solved this by moving my shared code to the App_Code folder (if there's a different/better way to do it please let me know).
Another issue that I am finding confusing is with pre-compilation. With VS 2003 I could click the build project button and it would precompile my site into a myweb.dll and myweb.pdb files. Now I'm having trouble doing the same in VS 2010. When I build the site in VS 2010 the dll is not created. I did manage to find an option to "Publish" the site which takes forever (like 2 minutes) and involves duplicating the site to another folder. This would have been acceptable but instead of making the single DLL file, it makes a bunch of files: App_code.compiled, app_code.dll, App_code.pdb, App_global.asax.compiled, App_global.asax.dll, App_global.asax.pdb, App_Web_lrpcway1.dll, App_Web_lrpcway1.compiled, App_Web_lrpcway1.pdb.
The application works - I can deploy it with all these files. However, I'd really like someone to explain what are the extra files and if there is a better way how to do it.
Thanks
This is the difference between a website and a web application.
You can convert your website to a web application to have it
behave more like you are used to.
The files in appCode are compiled when required to run and thus
does not provide dll.s in the bin/debug folder, but they should
be created when the application actually runs (but it is not
put in the same location).
Here is a nice write up about it Link
You can use the ASP.NET Merge Tool to combine all of the little DLLs into one big one.
http://msdn.microsoft.com/en-us/library/bb397866.aspx
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.
We are facing a very weird situation using Visual Studio 2005:
There is a Web Site project we do have, and VS when compiling the project automagically adds some undesired references, like 'System.Data.Oracle' (we don't use Oracle at all, and never did) and things from asp.net 3.5 (the project is 2.0, we don't use in it anything related to the new version).
As a consequence of this, when putting the published site into the production server (configured for 2.0, without these strange dlls), the site doesn't work. Even if we remove these dependencies from Web.config file.
Have any of you ever seen something like this happening with your VS05?
Note: the bin folder doesn't have these dlls.
Save your sanity and stop using Web Site Projects. They were an abomination from the get go.
The conversion to Web Application projects is well worth the effort.
Are you using Visual Studio 2005 SP1? You should be. There are bug fixes in addition to the fact they added Web Application Projects back.
VS2005 isn't inventing these references. Something in your web site is using them.
Are you precompiling the site prior to deploying it?
We could resolve it!
The web site project references a project.
This project had all these references, and the web site used them.. Removing the undesired references resulted successful ;)