I have problem with IIS. I googled it but couldn't find a solution. I tried to change my config file but it didn't work. If you want any additional information I'm gladly add it. Thank you for all.
Here is my IIS settings
Here is the image of when I try to debug my website from visual studio 2015 (And my awesome paint skills :) )
Here is the image of my visual studio settings for web
It is some internal design of IIS configuration system that in rare cases such an error page comes without the actual line number for the real error (note the line 0 in the error page).
Based on my investigation so far, the most obvious cause can be a missing section definition in IIS schema folder, which probably breaks the XML parser.
The common module that leads to such missing section can be out of band IIS modules shipped as separate MSI downloads from Microsoft.
URL Rewrite module is probably the most likely culprit in this case, as people use it so often, but it is not included in the default IIS installation. Note that it can still be caused by other OOB modules.
A better way to analyze the problem, is to run Jexus Manager (http://jexusmanager.com) which features an XML written by me, which can tell exactly what section definition is missing.
Related
I have what is basically a default ASP.NET Core 2.2 project created from the default Razor Pages templates.
Now, in solution explorer -> Dependencies there is a node called "Analyzers".
First of all, at first I had no idea what it was for. I think I know now but it's still kind of fuzzy.
Secondly, why does it have a warning icon? Same with its child nodes.
Note: I'm not under the "NuGet" node, so this is not a question about missing dependencies or anything like that.
And thirdly; why is this "feature" there if it's only there to confuse me?!
I had the same issue. After I restarted Visual Studio with Administrator privileges, Analyzers titles started to show the name instead of the path and the "warning" is gone.
EDIT
There is a GiHub issue about it.
A temporary fix would be to close the solution and to delete .dtbcache file in the .vs folder.
The warnings under each analyzer assembly are issues found in your code. Found by rules in those assemblies.
With the introduction of the Roslyn compilers it has become easier to analyse your sourcecode even before the compiler runs. These rules are packaged in special nuget packages. When these rules run they show in the error window and in this list.
If a rule misbehaves, or you want to turn it off or you want to look at just the MVC rules, this view is quite useful.
When analyzers themselves run into issues (some are not as good as others) the respective issues are also shown here. It looks like the RS* rules are actually issues with the rules themselves.
In my case, the warnings disappeared after I set net core 3.1 as target framework in project properties.
I've had the same issue. I think its because of the "C:\Program Files\dotnet" folder perssion.
you can open the visual studio by Run as Administrator or give the folder all permission in security folder. I did it and my proplem was resolved.
I have a problem which has received plenty of attention which, despite much googling, I have been unable to resolve. I have a Test Project attached to my Visual Studio 2010 MVC 2 Application. When I attempt to run my tests, I get:
"no tests were run because no tests are loaded or the selected tests are disabled."
Following this, I followed the instructions in these posts, to no avail:
MSTest: No tests are run because no tests are loaded or the selected tests are disabled = my GUIDs are right, and the assembly IS being built - I can see the file in explorer.
MSTest Not Finding New Tests = reopening the solution & rebuilding didn't result in any change
http://richallen.blogspot.com/2008/05/ms-test-re-enabling-ignored-tests.html = the tests do not even appear in the test list browser under "loaded tests"
Furthermore, the output console reports:
"Could not load file or assembly 'file://\shared\shared\IT\Development\TPS\TPS.Tests\bin\Debug\TPS.Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"
I have confirmed the build settings on the Test Project are the same as those for the main project (Any CPU targeted).
Therefore, is it a problem accessing the resource over network share? Otherwise, does anyone have a suggestion?
If you want to continue using a network share to host assemblies in .NET 4, you can change a Visual Studio configuration option to grant those assemblies full trust. You need to edit C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config and add the following line:
<loadFromRemoteSources enabled="true"/>
To the configuration/runtime element. This is described in (slightly) more detail at http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx. I would not recommend making this change without understanding the security implications of doing so, some of which are outlined in that MSDN article.
In general, though, I agree with the previous answer. Hosting Visual Studio projects on a network share is going to create a large number of problems for very little benefit.
Having your source code on a share is plain wrong (period) and will lead to all sorts of 'gremlins'.
Do yourself a favour, use Source Code Control and have a local copy of the source code. You will waste a lot less time, and as a bonus you will be able to track who changed what.
If you go with TFS, the Visual Studio TFS Branching Guide 2010 is a valuable resource.
If you use SubVersion, then the Red Bean Book is excellent.
I was running all local but still had the problem. I found that what caused it was removing an xml tag during manual editing.
add:
CodedUITest() inside of tag brackets
on the line immediately above your class where all your test methods are.
add:
TestMethod() inside of tag brackets
on the line immediately above your test methods you want to run.
build project and run.
I tried the following steps while encountering this problem and luckily the issue got resolved...
Close the solution and open the empty VS editor and Check out the testrunconfig file
Open the solution and under CodeCOverage column, uncheck and check the dll's available( these dll's would be having a warning symbol)
Rebuild the solution and now run the test cases.
Hope this resolves the issue... :)
I struggled with this for days, and didn't find the answer (for my situation) anywhere, so though I'd jot down my experience...
So I had the same problem, doing what I thought was local testing on a test project created locally.. (I'm a novice...) but returning the same error mentioned above : /
Anyway it seems that VS2010 had by default placed my project dir within the library folder, which was classified as network, subsequently all files within were 'unavailable offline'.
By moving my project dir to c:// my project files became index-able. (much to my relief!)
we've recently stumbled across the excellent Dispatch for ASP FTP deployment plug in. It looks great apart from one thing: It doesn't work with Visual Studio 2010, at least for us, anyway. (It's supposed to work fine.)
(Yes, we've tried everything: We've managed to get Dispatch working for another FTP site, but not the main one we regularly deploy to. We have managed to connect to our main site through FileZilla FTP, so the site itself is configured correctly. All settings have been triple checked, but the software still throws up weird errors (always to do with its internal libraries).)
So does anyone know of any other comparable FTP-based, deployment plug-in for Visual Studio?
Here's what Dispatch does (and so any suggested replacement must do):
Monitor any altered files
in the project. When a file is
changed, it's added to a list of
files to be deployed.
To deploy these
files to the live site, all we need
to do is click "Upload" and the plugin will
connect via FTP to our live site and
upload the selected files.
We can filter out
any filenames we don't want to be
monitored/uploaded (e.g. .cs or
web.config or /Images/, etc.)
I think that's all the features that we need. Thanks for any suggestions!
Note: If you're wondering why we need such a service, it's because we deploy many site changes over the course of a single day. Publishing the entire project to a folder, zipping it up, then FTPing that zip file, only to have to unzip it, and then install the entire project into the live wwwroot takes far too long. With Dispatch you're able to upload individual files in a single click.
After much back and forth between me and the creator of Dispatch, we managed to narrow down the problem to the library he was using (Rebex FTP). I posted a question about the issue on the Rebex forums, and it was revealed that their software might have a bug with IIS7.5. They suggested a quick hack/fix, which I tested and discovered worked.
Mr. Dispatch then quickly implemented this hack/fix into his software, and lo! I had a fully working copy of Dispatch... So no need for a replacement any more!
(And from what I've seen, there isn't even any other plug-ins offering this functionality, so it's just as well.)
Just an update - Dispatch does not work with VS 2013 so if you have VS 2012 with Dispatch installed, Keep it. Also the website is gone so it looks like all development has ceased. I have been using Dispatch since VS2005 and it has been great for just sending single files up when I need to. Too bad it is gone.
I built a very simple one for myself - you right click the file in Solution Explorer and it then uploads that file based on a settings file you create.
It's super crude but it works and the source is there to make it better if you like -
https://github.com/garazy/vs-2017-ftp-upload
Big enhancements have been added to VS2008, VS2010, VS2012. Below is the article. I found that Microsoft did all the above while I was searching. Since this came up high in what I was searching, thought should share this knowledge.
Deploy a Web Application Project Using One-Click Publish Without Web Deploy
I created an ASP.NET MVC 2 application in Visual Studio 2008. I set the release build to go through the ASP.NET compiler to precompile all the views, minify Javascript and CSS, clean up the web.config, etc. Since the production deployment is going to an IIS6 server, I set up my pseudo-production deployment on my Windows 7 machine to have the application pool run in classic mode targeting the 2.0 runtime. I set up the extensionless handler in the web.config that's necessary and everything worked great.
The problem came when I upgraded the solution to Visual Studio 2010. I'm still targeting the 3.5 framework, but now I'm using MSBuild 4.0 since that's what Visual Studio 2010 uses. Everything still compiles correctly because it runs fine under Cassini, but when I deploy it to the same location (same application pool, identity, etc) it now behaves differently. I still have the extensionless handler in the web.config, but now when I navigate to the root of the application it does directory browsing, and any routes that it had previously handled now come back as 404 errors being handled by the StaticFile handler in IIS. I'm at a loss for what changed and is causing the break.
I have looked at this question, but I have already verified that all the prerequisite components are installed.
Did you try debugging your routes using Phil Haack route debugger on the server?
Edit:
On IIS 7.5 you dont need any special extensionless handler, this is handled automatically, you don't need to change anything. It is only necessary on IIS 6 as far as I know.
Could that be the problem? what if you remove that special handler? maybe this is what is stopping it to kick in the route engine.
Edit:
I double checked, and as I thought, starting on IIS7, the default mode of a AppDomain is Integrated Mode. This means that the Asp.net stack kicks in at every request, while in classic mode, asp.net was called only when an specific extensions where called (aspx ashx axd are mapped by default to the aspnet_isapi filter).
UrlRoutingModule is kicking in at every request without requiring anything from you because it is an HttpModule and not a Handler. (it just needs to be registered in the config file of your application, no need to map it to an extension, but that's by default in an MVC app. You can open you Web.Config file and verify that you have under a node
<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>
Are you sure you deploy the MVC assemblies to the server?
Check that System.Web.Mvc, System.Web.Routing and System.Web.Abstraction references have the Copy Local property set to true to be sure you use the same assemblies locally and on your production server...
If all that is correct, I don't know how to help you more... I hope this will help you, or at least put you on the right tracks.
EDIT:
Oww... just read your last comment... sorry I missed that element about classic mode. Your title mentions IIS7.5 and I assumed too much things. that's why I got confused.
Honnestly now, I had to look in the book of Steven Sanderson. He has a checklist for troubleshooting IIS6 deployment.
I know you're saying it's only when using MSBuild 4 that it fails, but it might still be usefull
Check that Default.aspx is set as default content page. That could be the source of 404.
Then to have extensionless urls, last time I deployed to IIS6 I used a simple wildcard map and I never had a problem...
If you're still in trouble sorry that I could'nt help... not that I didnt try :) good luck
I experienced this problem today, in a similar scenario.
The problem on my case was due the fact that asp 32 bits was registered instead of the 64 bits, causing the problem with the routing.
It was solved by typing the following in the command prompt
CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i
Couple ideas to try
Have you run any kind of comparison
between the output of the VS2008 and
VS2010 projects? Just verifying that the
solution upgrade didn't change
anything.
Do you have the web.config
targetFramework attribute set on the
compilation element?
Are you certain you're not running
into something like running a x86 application
in a x64 app pool?
I'm guessing you're fine on those, but since Cassini has no problems with the application, I still lean toward web.config issues. Do you have your modules/handlers properly registered in the element? Since you're running Classic Mode, you'll need both the "old" and the "new" (reference 1, reference 2).
I've already posted this solution in another thread, but I'll repeat myself.
Use classic pipeline mode of AppPool:
Also dot't forget to install HTTP Redirection module in Turn Windows features on or off.
I have a web site that built on Visual studio 2008 and
i need to run it from my computer (Win 7 Ultimate) as a server
I tried to publish it to IIS and this is simply not working
and i have the flowing error :
Error Summary
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
any one can help?
It looks like the Web.config file contains some disallowed section. Some sections can only be set in the machine-wide configuration, some can only be set at the root of a web site, etc.
Simplify your web.config as much as possible (make it as empty as possible) and when the page displays, add one section at a time.
Silly problem but IIS never warn about it
i have missed installing the component (from control panel) that support ASP.NET
when i installed it ,it worked :)