We use a CI server (Jenkins) to compile an ASP.NET project and deploy to our web servers.
I want to precompile the site before deployment to increase performance, so I've set the PrecompileBeforePublish property in the Publish Profile (.pubxml).
However, when Jenkins runs the build, the AspNetPreCompile task fails with the error:
AspNetPreCompile:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe
-v /
-p c:\jenkins\workspace\DeployJob\MyProject\obj\Release\AspnetCompileMerge\Source
-c
c:\jenkins\workspace\DeployJob\MyProject\obj\Release\AspnetCompileMerge\TempBuildDir
ASPNETCOMPILER : error ASPRUNTIME: The current identity (JenkinsUser)
does not have write access to
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files'.
Note that this is not the machine where the web site will be deployed to, it is just a build server. I could grant the current identity (JenkinsUser) access to the Temporary ASP.NET Files folder, but I'd rather not have to mess around with filesystem permissions on a box that is just acting as a dumb Jenkins slave.
Is there any way around this? Why is aspnet_compiler trying to write the site to the Temporary ASP.NET Files folder, and is there any way to make it use a different temporary directory instead, such as %TEMP%?
I guess you could play around with this:
<AspNetCompiler ToolPath="C:\Windows\Microsoft.NET\Framework\v2.0.50727" VirtualPath="temp" PhysicalPath="$(ProjectDir)\..\Web" />
But you're gonna have to give ~some directory the rights.
It's just one of those "live with it" things.........my instructions document for setting up a CI machine has the "give rights to asp.net directory" as you explain.
Related
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.
Hello I want to build a build pipeline for a website. Whenever someone pushs something to git I want to trigger an action which builds the website (got that working with teamcity) and automatically deploys it to a staging server (docker container on some linux vps)
I could upload the artifact per ftp and check the ftp folder on the server per cronjob or something similar. But there has to be a better solution. Can you help me with that? Thank you.
TLDR I want to build, deploy and restart a website on every push to git.
Everything is selfhosted. No AWS, Azure or similar
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.
In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
EDIT
The command line that works fine for publishing is
MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=
In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.
Some answers to your questions.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can
this be done? If I leave the username and password empty, I am
prompted for it. Is there a way like manually modifying the .pubxml
files?
Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know.
If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in
PublishProfileName.pubxml.user that is local to each user? I could
at least save the username but obviously don't want that to be checked
in.
We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.
If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.
We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of
The Configuration itself is not part of PublishProfileName.pubxml but is stored in
PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.
The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way:
msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.
You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.
To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.
Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.
By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.
Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.
The answer to this may be a link to a good tutorial, but I've been unable to find one and it's getting rather frustrating.
I'd like to dive into the source code of DotNetNuke 5.2 which I have downloaded to a folder. I've opened up the solution that ships with it and it opens & compiles just fine.
What are the recommended steps for:
Setting up the database for this
source/compiled version of DotNetNuke?
Configuring IIS 7 (on the local
machine) to run/serve the site?
(Windows 7, VS2008, SQL-Server-2005, DotNetNuke 5.2)
FOr the setup you will follow the standard installation process, using the /website folder as the root for the configuration within IIS.
I have an installation tutorial on my blog that you can use, the specific tutorial is for 5.0.0, but the installation process is the same. The short order process is as follows.
Create a database and SQL user for the database, giving them DBO permissions
Setup a virtual directory in IIS that points to the /website folder of your dnn installation
Grant the ASP.NET worker process account full permissions to the /website folder
Navigate to the /install/installwizard.aspx page, follow the instructions and set the database values for what you specified in number 1 above.
NOTE: the use of a source version of DNN for production use is not recommended, additionally it is my personal recommendation to not modify the source, unless you are truly willing to accept that future upgrades might not be possible due to your modifications.
Expanding on Mitchel's Answer:
Create a database and SQL user for the database, giving them DBO permissions
Go into DNN/Website folder. Copy release.config and name the copy web.config
Setup a virtual directory in IIS that points to the /website folder of your dnn installation
Open the solution and compile the project
Grant the ASP.NET worker process account full permissions to the /website folder (NETWORK SERVICE)
Had to give users group read/write/modify access to the entire website folder otherwise I got some errors about file access. This is more than is necessary but it worked.
Navigate to the /install/installwizard.aspx page, follow the instructions and set the database values for what you specified in number 1 above.
Edit: This is as of version 5.2 available 2/25/2010