I have a very simple ASP.NET MVC 4.0 website. It's got a single controller ("HomeController") with a single action ("Index") which receives a single parameter ("string id"). I have not modified the global.asax file since this kind of route is handled by default. I have not created a view for this action since the action will simply be "sending" the user a file (a PDF). If I run the site from within Visual Studio (using a default page of "home/index/3" in project properties), the page runs fine. If, however, I publish the site to our test server (https://ourserver.com/mysite/home/index/3), I get a 404--File or Directory not found.
NOTE: We're running IIS7.5 on this server.
UPDATE: The bin dir (and the appropriate DLL, i.e., one named after the project) and the web.config file are there.
So, why is this not working?
If you're using an older version of IIS and haven't installed the MVC server extensions which give you routing, you can do a BIN deployment of the necessary infrastructure files.
Edit: If you're running IIS 7.5 you should have everything you need. You mention you don't see a web.config file or any dlls - how did you publish? You should absolutely have a web.config at the root of the publish directory and a bin folder with your dll(s).
If you right-click on your web project and do Publish, you can publish to a local directory. It'll be exactly what you should see when deployed.
Edit 2: Did you check that it's configured in IIS as a web application and not just a site?
Related
I have two separate .NET6.0 projects for back-end and front-end. Backend with C# can be published just fine. Front-end is written with Blazor. When I choose publish, it goes through the process without errors or exceptions. It also builds files in the bin>Release>net6.0 directory just fine but doesn't create any of the DLL files in my chosen directory for publish. In that directory, it just creates wwwroot, libman.json and web.config as you can see in the image.
Where can be the cause of the problem?
blazor web assembly app is a static app so it will have much static files, the logic codes you wrote in .razor will be packaged into your_project_name.dll in wwwroot\_framework.
Then when we need to host the app, we need to find a static file server to serve the app. For example, IIS. When publish the static app, we need to create a website and set the website point to the publish folder which containing wwwroot folder and web.config file. Then make sure the IIS had installed url rewrite module since it's a static website. After installing the module, we will see the default rewrite rule like this:
I am having troubles hosting the blazor wasm asp.net core hosted application.. The solution has 3 projects: Client, Shared, and Server.
when I run the command dotnet publish --configuration Release it publishes the libraries to their respective folders in solution like this:
WebWorkbench3\Client\bin\Release\net5.0\publish
WebWorkbench3\Server\bin\Release\net5.0\publish
...
I would assume that since the server project is referencing a client - then my steps to host the application are following:
Open WebWorkbench3\Server\bin\Release\net5.0\publish in powershell
Run command dotnet .\WebWorkbench3.Server.dll
Navigate to: https://localhost:5001/
Result:
Expected: client page opened
Actual: page is stuck at "Loading.." string. In the console we see that there was an error about _framework/blazor.webassembly.js not being loaded.
If we were to check the wwwroot folder contents in the server app we will see the following:
So this explains why the error is shown. However my question at this point - should the publishing process/configuration in project take care of copying client's wwwroot contents into the the server's app output directory? If we start a debugging session in the VisualStudio, then we use the server as the startup point, so the project should have some idea where to look up the blazor.webassembly.js file at..
So why doesn't the same process occurs during the publishing?
Note: I was able to fix the issue by manually copying the client's wwwroot directory and by placing the contents into the server's wwwroot directory... But I don't think that is is how serving is supposed to work?
EDIT: I have just tried to set-up the client blazor application in IIS. And it works. Kind of. The page is opened. But then when it tries to make a REST GET request to the server - it uses the same hostname:port combination. So if my app is hosted on mysite.local:50001 then the request to API will look like mysite.local:50001/data/loadall where data is the controller name and loadall is the action name.. So basically the client uses the same base address as the server.. The problem, is that I cannot start the server on the same port as the client! In attempt in doing so - you will see following output:
So basically I have the same question as before - how to host the wasm application that is split between client and the server? I am pretty sure that I can make it work by forcing the client to use the non-standard server port and serving the server part on that port.. However, I believe there should be a reason why current configuration (default configuration in the blazor wasm template) is configured in this way so it should be possible to run the project somehow without any additional changes at all..
Well this will be a self-answer.. Instead of publishing (dotnet publish --configuration Release) the application on solution level - do the publishing on project level..
before ..\repos\WebWorkbench3\WebWorkbench3
after ..\repos\WebWorkbench3\WebWorkbench3\Server
In 1 case the compiler does not copy the _framework folder (and possibly some other files) into the wwwroot.. Once you have published the Server correctly you can access the app by serving it with dotnet .\WebWorkbench3.Server.dll command.
Having the samie issue as explained above:
Before:
The solution file
had the same name
was in the same folder
as the server project
Resolved
I moved the solution to the project root (one level up).
Now, dotnet publish within the server project produced the __framework folder + content as expected.
I am looking to move some .NET Core applications into production and with the old .NET framework you could update the compiled DLL's for the application's code at any point.
The next time the application pool recycled, you would get your new code - or you could recycle the app pool manually.
With .NET Core, it appears that the running application locks the DLL and it cannot be overwritten until either the process is closed through inactivity, or is ended via Task Manager (Window's server here).
Is the a preferred method to publish a new version without having to set a maintenance window for all the users? This is on a Windows 2012 R2 server running the .NET Core framework via IIS 8 and the App Pool having no managed code.
For ASP.NET Core hosted with Kestrel runs in separate process and IIS works like Reverse Proxy. So there is not way for DLL release unless you implement it you your application.
Set up a hosting environment for ASP.NET Core on Windows with IIS, and deploy to it section Deploy the application, item 4.
If you want to avoid downtime simply setup two websites on IIS with same set of settings, make an update on second website, put first down, and start second.
I think the simplest way is to copy all files into a fresh folder and changing the physical path of the web site.
For example, you have all web sites under C:\WebSites, you also have a subfolder for each web site such as C:\WebSites\MyWebSite and a subfolder for each version, such as C:\WebSites\MyWebSite\V01.00.
To deploy a new version V01.01, create a new subfolder C:\WebSites\MyWebSite\V01.01 copy all files to that folder and change the physical path of the web site.
You can easily change the physical path with PowerShell:
Import-Module WebAdministration
Set-ItemProperty -Path "IIS:\Sites\MyWebSite" -name "physicalPath" -value "C:\WebSites\MyWebSite\V01.01"
This is a form of "hot publishing". Additionally you can easily roll back to the previous version if something goes wrong.
Another alternative is to use symbolic links, for example C:\WebSites\MyWebSite may point to C:\WebSiteVersions\MyWebSite\V01.00. To deploy a new version, copy all files to C:\WebSiteVersions\MyWebSite\V01.01 then change the symbolic link so that C:\WebSites\MyWebSite points to C:\WebSiteVersions\MyWebSite\V01.01, and finally recycle the application pool. Click here to see code for doing that
There is also another option called "blue green deployment" strategy. This strategy requires configuring a single server web farm and two web sites. Please see this article for a complete description.
I created empty project asp.net 5 in Visual Studio 2015.
Here how it looks:
As I understand from some tutorials the bin folder have to be inside wwwroot.
But there is no bin inside wwwroot and also bin folder not exists anywhere in Sensor Observation project.
Any idea why bin folder not exists inside wwwroot in my project?
The wwwroot folder is from where you serve static files (e.g. css, images, JavaScript, etc.). Files in the bin folder should never be served to the client (e.g. browser) so it should not go in the wwwroot folder.
Here is some more information on what the wwwroot should contain. Essentially:
"Enter the wwwroot folder in ASP.NET 5. The wwwroot folder represents
the actual root of the web app when running on a web server. Static
files, like appsettings.json, which are not located in wwwroot will
never be accessible, and there is no need to create special rules to
block access to sensitive files. Instead of blacklisting access to
sensitive files, a more secure whitelist approach is taken whereby
only those files in the wwwroot folder are accessible via web
requests."
The wwwroot/bin folder only used to contain one single file AspNet.Loader.dll. The AspNet.Loader.dll was/is used by IIS to load the application (which resides outside of the wwwroot folder).
The reason for this is an increase of security. With ASP.NET Core 1.0 you don't point the application entry to the folder (that contained all the *.cs files in ASP.NET 4.5), but you point it to the wwwroot folder of your application.
Now IIS don't has access to the actual application files (and allow by accidental access to maybe sensitive files). So the AspNet.Loader.dll is required to execute your application.
Other than that, there are no other binary files in wwwroot/bin nor should there be any other.
Update:
This used to be required for Helios to be run/hosted within IIS. Helios has been deprecated with beta8, because it made no sense to develop two different servers. So wwwroot/bin will always be empty for newer versions of ASP.NET Core. If you found posts or references, they most likely reference to an old beta.
Now Kestrel, IIS via HttpPlatformhandler (up to rc1-final version and ASP.NET Core Module with rc2 and newer) and self-hosting via HttpListener are the supported run modes. Though one can also use Kestrel behind an IIS.
I have locally made a simple helloworld web service (.asmx) that I want to test.
I have an enviroment where I already have it uploaded to the Team Foundation server, in NAME\CustomerApplications\TestService\TestService\service.asmx (the whole project is located in that structure).
The TF server and the IIS server are on the same machine.
Now, how do I deploy service.asmx file so I locally can get a path to the service like this: http://serverip/../service.asmx?
The "simplest" way to get an asp.net website/service working (manually) in IIS is to do the following:
Create a folder for it under c:\inetpub\wwwroot (assuming that you have your web root pointing there).
Copy all the service.asmx, .config files and the bin folder into the folder (assuming that you've compiled it at least once so that the bin folder contains dependencies and the compiled product of your service, i.e. the service.asmx.cs file)
Use "Internet Information Services (IIS) Manager" to navigate down to MACHINE NAME > Sites > Default Web Site > TheNameOfTheFolderCreatedInStep1
Right-click on the folder and choose "Convert to Application"
Choose the appropriate application pool by clicking on the "Select..." button (i.e. .net 2.0 or .net 4.0)
Click "OK"
You should now be able to navigate to http://serverip/FolderNameCreatedInStep1/service.asmx.