I've got a .ps1 file that I would like to link readers to. Unfortunately, navigating to that URL only results in a 404. If memory serves, this is being "blocked" just like .config files, but there's a way to change that configuration in web.config ... but I can't seem to find the correct thing via search.
TL;DR, how can I expose a .ps1 powershell script so that it's accessible (though not executable, obviously) via HTTP.
I believe you need to add a MIME type for .ps1. In your IIS Manager, select the server node on the tree, and click "MIME Types". Then click "Add..." on the right panel. For extension, set it to .ps1, and set the MIME type to text/plain.
Now IIS should serve .ps1 files.
You could use a MIME Type of application/octet-stream instead of text/plain. Using the former will cause most browsers to download it rather than try to display it.
You can do this for a specific web application or virtual directory, too. If you are doing this through web.config, it would look something like this:
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".ps1" mimeType="text/plain" /><!-- or application/octet-stream -->
</staticContent>
</system.webServer>
</configuration>
We used this same strategy for continuous integration with IIS static site resources - the powershell to do this same action is below in case this helps others wishing to script this change for CI. We were receiving HTTP 404s when asking for unlisted or non-standard file types (sql, ps1, etc.).
Add Additional Static MIME Type to IIS (.ps1)
Remove-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/staticContent" -name "." -AtElement #{fileExtension='.ps1'}
Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/staticContent" -name "." -value #{fileExtension='.ps1';mimeType='text/plain'}
This is re-entrant to support repeatable release deployments / desired state, etc.
Related
I want to prepare a pre-compiled package of ASP.NET MVC 4 site.
I can precompile it using commandline as follows:
aspnet_compiler -nologo -v / -p "C:\WebSite1" -u "C:\TargetPath"
However it baffles me, why aspnet_compiler requires virtual path. What if I decide later on to deploy this package to an IIS server under different path? Could it cause some run-time problems?
By deployment I mean here simple xcopy deployment.
If you specifiy the physical path of the source with the -p switch, then the virtual path is required. I reluctantly submit this page http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/precompiling-your-website-cs for some info on how the -v can play in with app relative references ie ~/path/file. What he says needs more qualification and does not appear to apply to apps under the default IIS site.
His explanation is that using -v /MySite will change references from ~/path/file to ~/MySite/path/file. However I have not experienced this behaviour. Atleast as far as compiling apps that are under the default IIS website (regardless of being on the root of the site or nested). If I compile with for instance /v kart, inline references and codebehind references to "~/path/file" arrive in the dll as "~/path/file", not "~/kart/path/file". I have had no runtime problems deploying my WebForm apps elsewhere where the app root is now at a different path.
If you are compiling apps that are under the default IIS website, it is redundant to use -p with the physical path to the source and -v with the virtual path. If you omit the -p switch it will compile the same as only using the -v. Being redundant with the -p and physical source path may be nice when reviewing a batch file to have the source location documented.
Using Windows 7 I have installed the IIS Express 7.5 but I cant find where is the wwwroot directory on my system! There is no "inetpub" folder on my C drive as well.
Can you please let me know where I can put a file like hello.aspx file to be run?
Thanks
By first-hand experience and also by this other SO answer, usually IISExpress holds a directory with its own data files at: C:\Users\<username>\Documents\IISExpress.
There you can find the default directories for each web site log files (Logs\ and TraceLogFiles\) and especially you can find all web sites configurations in file config\applicationhost.config. That one has a <sites> section with a <site> node for each website created.
For each website, its <virtualDirectory> node specifies actual root location in physicalPath attribute:
<site name="YourWebSiteName" id="12345">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="D:\Physical\path\to\your\website\root"/>
</application>
...
</site>
C:\Users\YourUserName\Documents\My Web Sites\web-Site1
One simple way to test is just key in a test file in your site root, e.g.
http://localhost:1714/test.txt
System will throw a 404 error, in the "Detailed Error Information" section, system will show the "physical path" the server is trying to retrive the file.
Usually it is in your home directory. Something like c:\Users\<yourname>\Documents\IISExpress
you will see a location like below path
C:\Users\YOURUSERSNAME\AppData\Local\Temp\Temporary ASP.NET Files
But where is the global directory for IIS Express? Quick answer is
that there is not one. IIS Express is very much directory based.
That being said, the 2 solutions I have been able to work out are:
Add the group of files to your root path of your web site
Create a virtual directory in IIS Express’ applicationHost.config file for the location of your global files
More details
I am trying to publish a Website project from a vendor that has ridiculously long paths to some of its files. When publishing, the error is:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
When I publish, Visual Studio 2012 Update 3 is attempting to write to a temp directory, and the prefix is quite long:
C:\Users\cuser\AppData\Local\Temp\WebSitePublish\MidasCMS400v9-1580334405\obj\Debug\Package\PackageTmp\
I thought I might be able to redirect VS to a different temporary directory at c:\tem by following this SO answer: Temp path too long when publishing a web site project
I create my publication profile, and as soon as I open it, there is an error indicating that WebPublishMethod is not an element of PropertyGroup. Regardless, I updated the file so it looks like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\Sites\MidasPublish</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
<AspnetCompileMergeIntermediateOutputPath>c:\tem\</AspnetCompileMergeIntermediateOutputPath>
</PropertyGroup>
</Project>
When I try to publish, I get the a modal box pop-up entitled "File Modification Detected", with the message "The project YourWebsite has been modified outside the environment", and it asks me if I want to reload. In my error list, I continue to get the error about the path being too long, as it is not attempting to use the c:\tem directory I identified.
I need to put this bloody thing onto a server, I am up for any solution that allows me to publish the bloody thing. I don't know much about the Website project template, so please let me know if there is a better way.
From http://forums.asp.net/t/1944241.aspx?Website+publish+failing+due+to+file+path+being+too+long
Add the following line in default PropertyGroup of web project file.
<IntermediateOutputPath>..\Temp\</IntermediateOutputPath>
You can likely make the above path C:\temp or ......\Temp (as needed to get it as close to root of the drive as possible.
In my case, there was no .csproj or .vbproj (website project file) but there was a website.publishproj file that warns you not to edit it, but I did anyway, and it did the trick.
Thanks to Stelvio, from http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation , there is a solution :
Well, I found a workaround that ALLOW work with path with more than 260 chars.
Disclaimer: I've tried this trick only on Windows 8 x64 and Visual Studio 2013
So, to make it work I've just create a junction to the folder with the mklink command:
Assume this is the original path: d:\very\very\long\path\to\solution\folder, you can obtain a short link as d:\short_path_to_solution_folder just jaunching this command from a dos shell as administrator:
mklink /J d:\short_path_to_solution_folder d:\very\very\long\path\to\solution\folder
change source and destination path to you needs
Best Regards!
Stelvio
from this link :
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation
While moving the project closer to the root file does work. I found a link to a solution that did work for me. The site also does a great job at discussion the issue as well as the details behind his solution.
Sayed Hashimi's solution to long path issue
EDIT:
To Summarize the provided link:
You can update your publish profile file, which is used by MSBuild, to include a replace rule that will shorten the path of your output when publishing to a web deploy package (Zip file).
For example, let's say publishing using the default profile created by Visual Studio, we get the following paths in the zip file:
archive.xml
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\bin
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\bin\WebApplication1.dll
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\index.html
Content\C_C\Temp\package\WebApplication1\obj\Release\Package\PackageTmp\Web.config
parameters.xml
systemInfo.xml
The trick is to replace all of the path defined after Content with a shorter path. In this particular example, replace the path with "website" in the PackagePath element.
One can edit the publishing profile file (.pubxml) and add the follow lines near the end of the file, just before the Project element is terminated.
<PropertyGroup>
<PackagePath Condition=" '$(PackagePath)'=='' ">website</PackagePath>
<EnableAddReplaceToUpdatePacakgePath Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='' ">true</EnableAddReplaceToUpdatePacakgePath>
<PackageDependsOn>
$(PackageDependsOn);
AddReplaceRuleForAppPath;
</PackageDependsOn>
</PropertyGroup>
<Target Name="AddReplaceRuleForAppPath" Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='true' ">
<PropertyGroup>
<_PkgPathFull>$([System.IO.Path]::GetFullPath($(WPPAllFilesInSingleFolder)))</_PkgPathFull>
</PropertyGroup>
<!-- escape the text into a regex -->
<EscapeTextForRegularExpressions Text="$(_PkgPathFull)">
<Output TaskParameter="Result" PropertyName="_PkgPathRegex" />
</EscapeTextForRegularExpressions>
<!-- add the replace rule to update the path -->
<ItemGroup>
<MsDeployReplaceRules Include="replaceFullPath">
<Match>$(_PkgPathRegex)</Match>
<Replace>$(PackagePath)</Replace>
</MsDeployReplaceRules>
</ItemGroup>
</Target>
Now, the publish profile paths should look something like the following:
archive.xml
Content\website
Content\website\bin
Content\website\bin\WebApplication1.dll
Content\website\index.html
Content\website\Web.config
parameters.xml
systemInfo.xml
The answer of Jason Beck worked to me with a small change. To avoid the error "The IntermediateOutputPath must end with a trailing slash." use the "\" at the end of the path:
..\Temp\
Your "CONFIG_PUBLISH_FILE.pubxml" should look like this (The "..." omits other configuration that you file may have):
...
...
..\Temp\
...
At the time of publishing the project, the visual studio compiler checks the size of the files that are part of the project.
So I searched for long names in files.
I found and renamed those files.
Did Work perfectly
In my case it was because the default legacy string length limitation of windows. This was still set to 256-character limit.
To fix this, from an admin powershell session I ran the following command
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
I needed to reboot the system for the changes to take effect.
Microsoft reference document link here
This error comes because of long path name....U just cut your folder from current location to D drive or F drive. suppose your project folder name is "myproject", and you should cut this folder and paste to D drive of F drive,that your current path name will be D:\myproject or F:\myproject. Then you publish again......It will work...
Is there a way I can run the Qt application as an administrator? I have an auto-updater for my application. It needs administrator privileges to replace the files in Program Files folder and hence it requires administrator privileges.
Running your application with administrator privileges does not have a whole lot to do with Qt. There are two approaches.
The "simple" one is to manually set your application to run with administrator privileges. You can do so by right-clicking on the executable. Then on the "Compatibilty" tab, you can choose to "Run this application as an administrator" under "Privilege level".
However, if you automatically want to achieve the same, you will have to embed a manifest into your application. What you're looking for is to set the requestedExecutionLevel to requireAdministrator. A bit more information can be found on MSDN or in this Wikipedia entry on UAC.
For your application as built in Qt Creator, it means you will need to embed the manifest by including a reference to it in a Resource (.rc) file. This resource file can then be added to your .pro file by specifying RC_FILE = myapp.rc. An informative blog post on this very issue is this one, as well as this post on the QtCentre forum.
A very simple solution for this, if you're using MSVC toolkit, is to add the following into the project file:
QMAKE_LFLAGS_WINDOWS += "/MANIFESTUAC:\"level='requireAdministrator' uiAccess='false'\""
I am using Qt 5.12 msvc2017.
I've found this to be quite neat, as from what I see in generated Makefile, Qt is already adding some manifest related link flags, and this approach wouldn't interfere with already embedding manifest, as manually adding manifest from existing file.
Other manifest link options can be easily added. You can read the docs for VS compiler, and/or you can check what flags/options Visual Studio IDE has to offer in Project properties/Linker/Manifest File and then check Command Line section of the Linker to see how it adds them.
Not sure how would this be done in gcc or clang builds, it would probably require solutions provided by #H Aßdøµ, and #Bart.
From the article that referred to Mr #Bart:
Application Manifest
First, we have to prepare an application manifest file. This one below is for application that does not require administrator rights:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="2.0.2.0" processorArchitecture="X86" type="win32"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Second, we need the MT.exe tool from the Microsoft Windows SDK to embed this XML in our executable. To do it use the following command:
mt.exe –manifest MyApp.exe.manifest -outputresource:MyApp.exe;1
Automatic Manifest Embedding
Manually executing the mt command after each compilation is a tedious task. What about convincing qmake to do it for us? After studying the docs it looks like the following line should do the trick:
win32 {
WINSDK_DIR = C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A
WIN_PWD = $$replace(PWD, /, \\)
OUT_PWD_WIN = $$replace(OUT_PWD, /, \\)
QMAKE_POST_LINK = "$$WINSDK_DIR/bin/x64/mt.exe -manifest $$quote($$WIN_PWD\\$$basename(TARGET).manifest) -outputresource:$$quote($$OUT_PWD_WIN\\${DESTDIR_TARGET};1)"
}
The above code will automatically execute the mt.exe program from WINSDK_DIR and embed a manifest file that is located in the project root directory and named after project's target (ie. MyApp.manifest). That's all to adding a manifest, now let's move on and specify the version information.
Orginal post: http://blog.strixcode.com/2010/08/embedding-application-manifest-and.html
We are using a custom config section (via the NameValueConfigSection) to contain our settings.
These settings are externalised from web.config via configSource.
So, entries in web.config look something like this:
<configSections>
<section name="customSettings" type="System.Configuration.NameValueSectionHandler" />
</configSections>
<customSettings configSource="config\customSettings.config" />
We want to encrypt this "customSettings.config" file on our production server, so run this command, as recommended by Microsoft (here: http://msdn.microsoft.com/en-us/library/zhhddkxy.aspx)
aspnet_regiis -pe customSettings -site 4 -app /
And this produces the following output:
Encrypting configuration section...
Succeeded!
However, it does not succeed at all, leaving the file exactly as it was
(incidentally, this command does work if encrypting a non-custom section, such as an externalised connectionStrings section)
I have been able to write a little console app that does work ok, but we really want to use the standard tools to do what should be a standard operation - can anyone tell me if this is a limitation or where I am going wrong?
Thanks :)
I'm comparing your code with this:
To encrypt the connectionStrings section with the DPAPI provider with the machine key store (the default configuration), run this command from a command prompt:
aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov "DataProtectionConfigurationProvider"
where:
-pe specifies the configuration section to encrypt.
-app specifies the web app's virtual path. If the app is nested, specify the nested path from the root directory, for example "/test/aspnet/MachineDPAPI"
-prov specifies the provider name.
I wonder if you need to provide the app name? And/or the provider?
And their version encloses the attribute values in quotes.