It's a question I see on here but solutions aren't working.
I have a Multi Project Solution set up like so
The sole purpose of the "Console" is to start/stop the "Controller", the "Controller" the handles the "Plugins".
"Console" is a Console Application the other projects are class libraries.
I've just added log4net to the "Controller" project to write logs to the database.
In DEBUG it works perfectly and logs to SQL.
However once built in release, published and deployed it is failing to log.
I've kept all the log4net config within the Controllers "app.config" and know this is being used because the "app.config" has some other settings present.
Attempted Solutions - ALL WORKING in DEBUG but not Published/Released Version
Changed SQL connection string to a USER & Password from Windows
Changed log4net to separate config file and setting build properties to CONTENT and COPY ALWAYS
Using the below code to configure log4net in either he "AssemblyInfo.vb or the "Contoller.vb" file
Assembly: log4net.Config.XmlConfigurator(ConfigFile:="app.config", Watch:=True)
Any potential ideas please?
NOTE:
If I remove the explicit ConfigFile:="app.config" LOGGING DOES NOT WORK
NOTE 2:
Setting an absolute file path on the server for the ConfigFile enabled the Published Installed version to work. Is this the best method?
I'm developing an ASP.NET Core 1.0 application which I deploy to a Linux machine using Docker.
In my CI pipeline I'm publishing the project using dnu publish, then I build the docker image with docker build.
I have a static binary file that I need to use in my docker image. (It's a hotfix which I need to copy into the coreclr runtime directory.) I want to be able to access that file with a command from my Dockerfile.
What is the idiomatic, reliable way to make that file get copied into the output directory when I'm doing dnu publish? What I'm currently doing - because I couldn't find a better solution - is adding it to wwwroot, so it gets copied into wwwroot in the output folder.
However, I don't want that file to be publicly accessible, it would be much better to make it end up in approot.
The approaches I found on SO and tried, but are not working:
Including the file in the project.json as "contentFiles": [ "mylib.so" ]. If I do this, I get the following error during the dnx build:
Error: The process cannot access the file 'C:\myapp\src\myapp.web\mylib.so' because it is being used by another process.
I tried to experiment with creating a custom postBuild script (found the suggestion here: New .NET "project.json" project, copying pre-built native .dlls to the output directory), but I can't figure out where to copy the file, since I have different CI pipelines publishing the same project using different publish output directories, so I cannot hardcode the directory path into my project.json.
Or is there a way to copy it into the build directory, which will be picked up by dnu publish regardless of the output directory of publish?
I am trying to find a way to run MVC6 application on IIS but without actually doing the publish. I am not sure if that is possible, and if not will it be possible in the future?
I would like to have similar behavior like on previous versions where I could easily debug my code and make changes while the application is running under IIS.
From your original question (emphasis added):
I am trying to find a way to run MVC6 application on IIS but without actually doing the publish.
From your comment to tugberk (emphasis added):
Right now every time when I make a change I need to call that dnu publish command in order to see my changes on IIS. I would like to see them only by doing rebuild.
Answer and reasons
You'll need to publish. There are at least two reasons:
IIS needs build output and
IIS needs a web.config file.
IIS might need a few other things too, about which I'm not aware. So, you'll need to publish. This isn't a big deal: after the onetime setup, publish doesn't take much longer than rebuild does.
Why do you need to publish?
In Visual Studio 2015, if you build an ASP.NET 5 web app, there will be no build output under your solution's directory, and IIS needs build output. By default Roslyn only runs code analysis without emitting build output.
You can change that default, so that Roslyn does emit build output, but that won't produce the web.config file that IIS needs. By going to View > Project Properties > Build and checking "Produce outputs on build", Roslyn will emit output to the artifacts directory. E.g:
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.nupkg
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.symbols.nupkg
artifacts/bin/MyWebApp/Debug/app/project.json
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.xml
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.xml
If you point IIS at the artifacts directory, you'll now have the problem of having neither a wwwroot nor a web.config.
So, you need to publish (or work out some other convoluted solution) for IIS to work with ASP.NET 5. There is a onetime setup if you want to publish from Visual Studio to a local IIS website. After the onetime setup, you can make changes to your code and publish in two clicks. Here's the onetime setup:
Right click the project.
Choose Publish.
Select File System and add a profile name (e.g. inetpub).
Change the target location to C:\inetpub\MyWebApp
In Settings, select appropriate settings. E.g.
Configuration: Debug
Target DNX Version: dnx-clr-win-x64.1.0.0-beta4
Click Publish.
Once publish completes, point IIS at C:\inetpub\MyWebApp\wwwroot and you will be able to browse to the web site. Further to the point, you can now change your code, publish in two clicks, and refresh your IIS site to see the changes.
Some gotchas
If you do choose to publish to inetpub, be sure to run Visual Studio as administrator, lest you receive an insufficient permissions error.
If you accept the default publish location (instead of using inetpub as shown above) watch out for path too long errors (i.e. > 260 characters.)
Final thoughts
Why not use Visual Studio and Debug > Start without debugging during development. With Roslyn and Visual Studio 2015, you can make changes to the code and see those changes by refreshing the web browser. No rebuild is necessary. It's a much nicer workflow.
It's possible. Under the root of your project (project.json directory), run the following command:
dnu publish --runtime active --out bin/artifacts
Once the publish is done, you have some stuff under bin/artifacts folder. Point IIS application pool to bin/artifacts/wwwroot folder we have just created and it should work. Keep in mind that you at least need .NET 4.5.1.
I'm assuming this is a development on IIS question. It's doable but it requires some work. The reason IIS doesn't work out of the box without a publish is because there is no user profile setup on app pools by default. The simplest thing you can do is to enable the user profile on the app pool, that will allow IIS to find the runtime in the user profile folder. On top of that, you require a web.config to specify which version of the runtime to use (dnu publish generates this for you so if you want, you can do a publish and copy the runtime folder). After doing that, pointing IIS to the wwwroot should just work (assuming you setup the right web.config with the right runtime and the right bitness).
You also need the correct AspNet.Loader.dll in the bin folder. If you use visual studio, it'll copy it in the right place.
Based on davidfowl answer i ran ASP.NET MVC6 on IIS without publishing application. But i still can't start debug it by F5(only by attaching to w3wp.exe).
Anyway i hope it would be helpful:
In the root of the project add "packages" directory(or name it whatever you like).
In global.json file add "packages": "packages". e.g.:
{
"projects": [
"src",
"test",
"wrap"
],
"sdk": {
"version": "1.0.0-beta4"
},
"packages": "packages" // <--
}
Packages will be now stored in this directory.
Create a "runtimes" directory in the root of your project.
Copy a runtimes from %userprofile%/.dnx/runtimes to /path/to/your/project/runtimes
Create a web.config in wwwroot of you project. e.g.:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="bootstrapper-version" value="1.0.0-beta4" />
<add key="dnx-version" value="1.0.0-beta4" />
<add key="dnx-clr" value="clr" />
<add key="dnx-app-base" value=".." />
<add key="runtime-path" value="../../../runtimes" />
</appSettings>
</configuration>
Create web application in IIS and point it to your project wwwroot.
My project directory structure:
Projects/
vNext/
packages/
runtimes/
dnx-clr-win-x64.1.0.0-beta4/
dnx-clr-win-x86.1.0.0-beta4/
...
src/
vNext/
wwwroot/ <-- IIS web application points here
web.config
...
project.json
...
global.json
vNext.sln
...
After this you will be able to attach to w3wp.exe and debug your application running under IIS.
In TeamCity I have created build step that is running MSBuild with target Package(not my script just MSBuild runner from TC pointing to csproj), then this package is deployed through web deploy to iis.
Problem is that deployment is creating new application under Default Web Site and I would like to deploy it to one already existing.
So I added parameter to build DeployIISAppPath=Default Web Site\ MySite and I have checked that in generated SetParameters file it actually is Default Web Site\ MySite but still this value is ignored and app is deployed to XXX_deploy virtual directory created by deploy.
Any idea why?
I converted a VS2010 ASP.Net MVC3 project to VS2013 MVC4. Now when I publish, it is copying the contents of my project to the bin folder.
I can't understand what I did to make it do this..How do I fix it so it doesn't do it?
Your files are incorrectly set to copy to the output folder (\bin) during build. Make sure that the Copy To Output setting on each file is set to Do Not Copy.
Normally, you don't need to copy much of anything to your bin folder. When publishing, all of the content pages (*.aspx, *.html, *.css, etc) will get picked up by publish just by existing in the project. This is determined by the Build Action being set to Content. (Note: you can exclude files by setting the Build Action to None)
For code files, there's 2 ways it could go. in a Web Application project (which MVC is) most code files, such as controllers, models, or code behind files in WebForms, are compiled into your site's DLL already. These have Build Action = Compile, meaning they get compiled up front and don't need to be included in the publish. The exception to this is files in App_Code, which are deployed to your site (Build Action = Content) and compiled at runtime. You can also choose to pre-compile your site in the publish settings (Settings -> File Publish Options -> Precompile during publishing), which will process the App_Code files automatically (i.e. you can leave them as Build Action = Content and VS will compile them and publish the output instead).