We have two environments on Azure (Same site, same config etc...) All deployment was scripted over ARM Json files and deployment by VSTS.
When I hit the first environment, everything is ok.
But on the other environment, I caught exception. After investigation, it seems Azure does not see my unity config files (XML files in UTF-8). When I open all my files via (App Service Editor (Preview)) Note: I only set a space on the file for update only. After that my web app run well.
At each deployment, I need to go via Azure Portal to edit my Unity.config files to fix my WebApp.
Anyone have an idea about it? And why my first site with the same file, config, deployment working well, but not the second one?
it seems Azure does not see my unity config files (XML files in UTF-8).
Please double check whether the encoding of your config file is UTF-8 before deploying it. You could take following steps to check it.
Open your config file using Notepad.
After clicked File->Save As..., you will see the current encoding of your config file. If the current encoding is not UTF-8, please change the encoding to UTF-8 and save the file.
Related
I distributed my xaf Winforms+Desktop Bridge app to myself via the Windows Store.
following this blog
From the blog, I want to pre-generate the ModelAssembly.dll, Model.Cache.xafml and ModulesVersionInfo file and package them to go in the output directory.
These files are generated by XAF if they don't already exist.
Where the output directory is given by
Path.GetDirectoryName(GetType().Assembly.Location)
When I install and run my app from the store. I get this error message.
Access to the path 'C:\Program Files\WindowsApps\JobTalk.JobTalk_1.0.19.0_x64__8kpaqbvntb9aj\SBD.JobTalk.Workflow.Win10\ModelAssembly.dll' is denied.
In the code I tried looking form Path.GetRelativePath but it is not available in Framework 4.7.2
In short, UWP app doesn't allow to access files via absolute path. Because UWP apps run in sandbox and have very limited access to the files out of the app container. In most scenarios, the UWP app can directly access only their install folder and their application data folder. Since the converted app also is a UWP app, so your app need to follow this rule.
Please check the Prepare to package a desktop application. The document has mentions some scenarios that is related to your question.
Your application writes to the AppData folder or to the registry with the intention of sharing data with another app. After conversion, AppData is redirected to the local app data store, which is a private store for each UWP app.
Your application writes to the install directory for your app. For example, your application writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
Here, there's a special scenario that you could access files via files absolute path. It's a restricted capability called as broadFileSystemAccess. Once you add the broadFileSystemAccess capability, you could use the APIs in the Windows.Storage namespace to get all files that the user has access to. Please read File access permissions for more information.
Please note that the document has explained:
If you submit an app to the Store that declares this capability, you will need to supply additional descriptions of why your app needs this capability, and how it intends to use it.
Xavier's answer explains what was going wrong. The reason it happened on my project was that I missed the step of marking the linked files as "Copy if newer"
When MSBuild packages an ASP.Net website, it creates a .zip file and a set of xml files. Using msdeploy, I can push that zip file and a set of parameter replacements to an IIS server.
Now, here's the conundrum: given that Web Package zip file, is there a way to unpack it and do the token replacement cleanly without deploying to IIS? Just unpack it to a folder and apply the SetParameters.xml so that it would be ready to robocopy to a file system location?
Msdeploy's parameters are opaque to say the least. I've tried deploying using the file and folder providers, and that doesn't work.
I could roll my own - I'd have to reverse-engineer the token replacement logic and deal with how the zip file contains the entire folder tree right down to the drive root (instead of being relative paths from the project folder, which is what it will use when it deploys). All of this is doable... but very annoying and I was hoping there was a better way.
Thanks in advance.
Following up on this: In the end I had to do it in powershell. The code is tied into a whole bunch of other deployment code that's company-specific, so I can't paste it here, but in short:
Unzip the .zip into a temporary location.
Recurse the directories until you find the packagetmp - this is the actual meat of the zip.
Delete the target web app folder on the webserver (carefully - as many sanity checks as possible need to happen before this step)
Copy the contents of packagetmp to the target folder-path on the web-server.
Apply use xpath operations to do the config transforms in powershell to provide connection strings and logging endpoints.
Restart the app pool (do not skip this step you get subtle failures if you do).
Clean-up (delete the temporary folder).
My question is ,if i deploy my project in the web , will all the files that will be uploaded still will be store in my hard disk? i'm new in mvc ,i don't know much it yet.sorry very new in mvc
Of course will not be on your hard disk cuz you set relative patch to upload/download file ("if i deploy my project in the web" - I guess it means deploy to external server, so i if you set static then propably program cause a error). Everything will be stored on device where program is running
Visual Studio 2015 has moved the IIS Express configuration file from My Documents into its own hidden .vs directory and tells IISExpress.exe to use that configuration file.
While this may sound like a good idea when you have multiple web applications with conflicting configurations, in fact it's not when you have web applications with custom configurations at all. Because this config file is in a temporary directory which can be deleted when checking out code into a new location from source control, or when cleaning up things in general.
The old location in the Documents folder is a central location and files there usually won't be deleted. If I need to make some changes to this file, like allowing the application to use Windows authentication, I edit this file once and I'm done. Now with the new location, I may need to make these changes multiple times. And since there's two config files (the old location still exists for me), it's even more confusing.
Then you shouldn't commit anything from .vs into version control, so it's not even possible to share these customisations with other team members.
What is the recommended way to update the applicationhost.config file so that it provides the environment required by the web application? Is there a tool that can run in a pre/post build step? Is there a customisation XML file that can be merged into the default file from .vs?
Is it possible at all to just check out a web application from source control and let it work in a local IIS Express? Or will it always require manual corrections after getting the code and web.config?
PS: I've forgotten one thing: There's the <UseGlobalApplicationHostFile> element in the project file which can be set to true, but as soon as I do that, I get an access denied error message every time I want to start the web application. So that doesn't seem to work well.
I am using Visual Studio 2008 and trying to publish a Web Application Project, but it keeps failing when trying to add files in the project. Below is a sample of the message;
Publishing folder JavaScript... Unable
to add 'JavaScript/hoverIntent.js' to
the Web site. Unable to add file
'JavaScript\hoverIntent.js'. The
specified file could not be encrypted.
This happens for image files too. I am lost as to why it is happening. I should add that I am using Windows 7 build 7100, not sure if this is casuing the issue??
Any help greatly appreciated
I know this is an old topic, but I found it when I googled for the same problem.
My solution was to remove the "Encrypt" flag from Windows Explorer for the files listed (Right click -> Properties -> Advanced)
This blog post at BlackMarble is suggesting that you may have the target directory set to use encryption. Sounds like the exception you're seeing is the inability for the VS publish process to handle that.
To get around this problem:
use VS to publish to an intermediate directory. Somewhere on your PC perhaps.
copy the files yourself (with a batch file maybe) to the server
That's a workaround, at least.
Disable windows encrypted file system in cmd with the following:
fsutil behavior set disableencryption 1
Then restart your PC.
When I had this problem on publishing a Visual Studio 2010 web project either to a local folder or to a host, I was stumped. Visual Studio didn't indicate which files or even folders had caused the problem. I wasn't aware there were any encrypted files in the solution and I couldn't find any. I was unable to update my website.
I googled how to find encrypted files but none of the solutions involving efsinfo.exe were appropriate to Windows 7 then I found an example using the cipher command:
https://superuser.com/questions/58878/how-to-list-encrypted-files-in-windows-7
There were a number of different answers to finding the encrypted files. I used the command prompt method.
I opened a command prompt in the root of my application and did:
D:\Data\Code2011>cipher /s:MyWeb >Encryption.txt
I then did a case sensitive search in Encryption.txt for lines beginning E[space] or 'the file is encrypted'
I found two .htc files which were encrypted in a styles subfolder and was able to unencrypt them in the advanced tab of explorer file properties.
The Web then compiled and published OK.
I had this issue as well. I set the source files properties to not be encrypted but that still wasn't working. Turned out that the files were cached in the temporary deployment folder and I had to uncheck encryption there as well. It probably would have worked to delete the temporary deployment directory but the other way worked.