I want to change the default favicon on my SharePoint site. I didn't want to change the masterpage, so I just replaced the favicon.ico file with the one I created (.ico) here: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\IMAGES. It still shows the default favicon even after I did iisreset. I would appreciate any suggestions / help. Thank you!
I made it work by uploading the generated favicon to [site]/SiteAssets/Forms/AllItems.aspx and then changing the following line in the master page: < SharePoint:SPShortcutIcon runat="server" IconUrl="[site]/SiteAssets/[your_favicon_name].ico" />.
Changing favico must be done by
Change the icon, as you suggested, in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\IMAGES
Empty any browser cache
Empty the IIS Temporary Cache if you have compression enabled C:\inetpub\temp\IIS Temporary Compressed Files\
(full path is C:\inetpub\temp\IIS Temporary Compressed Files\SharePoint Central Administration v4\$^_gzip_C^\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\15\TEMPLATE\IMAGES)
Stop IIS and emtpy the temporary internet files, Start IIS
Run in PowerShell to delete Temporary ASP.NET Files
net stop w3svc
Remove-Item -Path "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\*" -Force -Recurse
Remove-Item -Path "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\*" -Force -Recurse
net start w3svc
Related
I have this powershell script which works very well on my computer. I use the x64 and powershell 7.2.
The problem is when I publish the code to Azure, there is a module missing. The module is a .net System.Data.OleDb.
ERROR: Exception calling "Open" with "0" argument(s): "The 'MSOLAP' provider is not registered on the local machine."
I have tried to add the .dll file to Module folder, that i created but function app doesn't load it for some reason.
Structure of the function app
host.json
local.settings.json
powerbitablerefresh
run.ps1
function.json
Modules
Microsoft.AnalysisServices.AzureClient.dll
profile.ps1
requirements.psd1
inside requirements I have:
'Az.Keyvault' = '4.*'
'Az.Accounts' = '2.*'
'Az.AnalysisServices' = '1.*'
'SqlServer' = '21.1.18256'
My question is, how do I install .dll on a function app?
how do I install .dll on a function app?
You can install .dll files by following below workaround:
Firstly, Login to Azure
Then open your Function App
Then Click on Advanced tools , then click on Go
Then Click on Tools, Then click on Zip Push Depoly like below:
Then Click on your function app
Then click on bin folder and after it opens, drag your .dll file over there and then you can reference them in your function app:
The right answer is that add the .dll files to the C:\home\site\wwwroot\ and then in the powershell script run it like this
Add-Type -Path (Join-Path $PSScriptRoot "Microsoft.Identity.Client.dll")
Add-Type -Path (Join-Path $PSScriptRoot "Microsoft.AnalysisServices.AdomdClient.dll")
It will then create a connection
We have developed a Blazor WebAssembly Application that has already gone into productive usage for a certain group of customers.
The Application works well in all Browsers with Standard Security settings. However, this morning I got a call from one of the customers, where the Application did not load at all in their Chrome Browser.
I saw the following Errors in the console:
Unknown error occurred while trying to verify integrity.
Failed to load resource: the server responded with a status of 403 (forbidden)
Failed to find a valid digest in the 'integrity' attribute for ressource '<somepath.dll>' with SHA-256 integrity <sha56>. the resource has been blocked
Now my question is, what could cause this? Is this a Browser Security setting, or another security setting e.g on server, in code etc.? How can I fix this?
Here's a picture of the errors mentioned above
The most likely reason why this is happening, is that some Antiviruses block the execution of downloaded .dll files. That's why it is working in some networks, but doesn't in some others.
What you can do, and what is also suggested as a Workaround by microsoft, is to rename all .dll to .bin - and also change the config json. it worked in my case.
I use the following PowerShell function for that:
Function Hide-BlazorDLL {
Param(
[string]$Path = (Get-Location).Path
)
<#
According to the following Links:
https://github.com/dotnet/aspnetcore/issues/19552
https://github.com/dotnet/aspnetcore/issues/5477#issuecomment-599148931
https://github.com/dotnet/aspnetcore/issues/21489
https://gist.github.com/Swimburger/774ca2b63bad4a16eb2fa23b47297e71
#>
# Test if path is correct and accessible
$WorkingDir = Join-Path $Path "_framework"
if (!(Test-Path $WorkingDir)) { Throw "Wrong path $Path. current location must be wwwroot folder of published application." }
# Get All Items
$AllItems = Get-ChildItem $WorkingDir -Recurse
$DLLs = $AllItems | Where-Object { $_.Name -like '*.dll*' }
$BINs = $AllItems | Where-Object { $_.Name -like '*.bin*' }
# End script if no .dll are found
if ($DLLs) {
# Delete all current .bin files
if ($BINs) {
Remove-item $BINs.FullName -Force
}
# Change .dll to .bin on files and config
$DLLs | Rename-item -NewName { $_.Name -replace ".dll\b",".bin" }
((Get-Content "$WorkingDir\blazor.boot.json" -Raw) -replace '.dll"','.bin"') | Set-Content "$WorkingDir\blazor.boot.json"
# Delete Compressed Blazor files
if (Test-Path "$WorkingDir\blazor.boot.json.gz") {
Remove-Item "$WorkingDir\blazor.boot.json.gz"
}
if (Test-Path "$WorkingDir\blazor.boot.json.br") {
Remove-Item "$WorkingDir\blazor.boot.json.br"
}
# Do the same for ServiceWorker, if it exists
$ServiceWorker = Get-Item "$Path\service-worker-assets.js" -ErrorAction SilentlyContinue
if ($ServiceWorker) {
((Get-Content $ServiceWorker.FullName -Raw) -replace '.dll"','.bin"') | Set-Content $ServiceWorker.FullName
Remove-Item ($ServiceWorker.FullName + ".gz")
Remove-Item ($ServiceWorker.FullName + ".br")
}
}
else {
Write-Host "There are no .dll Files to rename to .bin"
}
}
Basically you need to navigate to the wwwroot folder of your published application and run the function there. e.g:
PS D:\inetpub\wwwroot\<appname>\wwwroot> Hide-BlazorDLL
Solution for me was to delete the obj and the bin folder in both the client and the server project folder
This error for some reason kept happening for me when I tested my application in an anonymous browser window (Google Chrome).
Try using a normal browser window if you're getting integrity errors.
Also, if you're using Cloudflare CDN don't forget to "Purge Everything" in the cache.
We have experienced this issue using Cloudflare auto minify feature. That feature removes any comments from html, js and other files - which some of the blazor .js files seems to contain.
This means that the hash of the file contents no longer matches the hash found in blazor.boot.json -> an integrity issue will be thrown and stop the app from loading.
Disabling the auto minify feature fixed the issue.
Tech Stack:
.NET 6.0.11
I had a similar issue. In the local machine, it is working fine. But when it is deployed through GitHub Actions, I get integrity checks error. I got this issue for Blazor WebAssembly ASP.NET Core Hosted (WebAssemblyPrerendered) project. Here is the fix I followed.
Added the .gitattributes file to the solution root folder.
Added the below code at the end of the file.
# blazor dlls - treat all .dll files as binary
*.dll binary
Recently, I was trying to add a Content Search Web Part using csom in Visual Studio 2017, While I was adding the "ContentBySearchWebPart" class, an error occured as:
"The type or namespace name "ContentBySearchWebPart" could not be found(you are missing a using directive or an assembly reference?)".
Even I was using the namespace as "Microsoft.Office.Server.Search.WebControls" and also the "Microsoft.SharePoint.Client.Search" dll.
How can I resolve this issue?
You need to add reference "Microsoft.Office.Server.Search.dll" manually from ISAPI folder or GAC
ISAPI folder
<Windows>\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\16\ISAPI
GAC
(C:\windows\Windows.NET\assembly\GAC_MSIL\Microsoft.Office.Server.Search).
Namespace: Microsoft.Office.Server.Search.WebControls
Assembly: Microsoft.Office.Server.Search (in Microsoft.Office.Server.Search.dll)
https://social.msdn.microsoft.com/Forums/sharepoint/en-US/c6f03ea3-f893-4126-88e3-52a2a66b5f18/missing-assembly-reference-for-microsoftofficeserversearch?forum=sharepointdevelopmentprevious
Check your \Program Files\Common Files\Microsoft Shared\Web Server Extenstions\14\ISAPI, you'll find alot more DLL's inside this folder including your Microsoft.Office.Server.Search.dll that you are looking for.
I'm tring to obtain file path for sharepoint 2013 location without hardcoding values on code.
I found the method GetGenericSetupPath,SPUtility class, wich has a strange behaviuor:
SPUtility.GetGenericSetupPath("Template")
reuturns
"C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\15\Template"
on the 15 hive
inhstead
SPUtility.GetGenericSetupPath("template\\LAYOUTS")
return a path on 14 hive
"C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\template\LAYOUTS"
finally the default path seems to be hive 15:
SPUtility.GetGenericSetupPath("")
"C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\15\" string
After some investigation i found this post:
The problem was that
SPUtility.GetGenericSetupPath Method IS OBSOLETE
and it returns a link to the 14 hive (SharePoint 2010), not the the new 15 hive (SharePoint 2013).
Instead of this we have to use SPUtility.GetVersionedGenericSetupPath(), where you can choose wich version of sharepoint use, so you can specify:
SPUtility.GetVersionedGenericSetupPath("TEMPLATE\\FEATURES", 15)
For whatever reason, when compiling multiple .resources files into a single satellite assembly (.dll) the resources will not show. Compiling a single resource will work. Here are the steps I used...
We have a project called "Report Viewer". This project is signed using a key, MySnKey.snk via Properties > Signing > Sign the assembly , choose a strong name key file: MySnKey.snk.
All forms have been updated to Localizable = True
We processed all the resx files into German de-DE. There are only two resx: MainForm.resx (project root directory) and Resources.resx (Properties directory).
I have a folder with MainForm.de-DE.resx and Resources.de-DE.resx which are the translated versions of these files.
Using resgen,
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" /compile Resources.de-DE.resx ReportViewer.Resources.de-DE.resources
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" /compile MainForm.de-DE.resx ReportViewer.MainForm.de-DE.resources
This creates the appropriate .resources files. Now to link, I use AL.exe:
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\AL" /t:lib /embed:ReportViewer.MainForm.de-DE.resources,ReportViewer.Resources.de-DE.resources /culture:de-DE /out:ReportViewer.resources.dll /template:../../../Output/ReportViewer/bin/Debug/ReportViewer.exe /keyfile:../MySnKey.snk
This creates a ReportViewer.resources.dll file. If I place it into the appropriate sub folder de-DE>ReportViewer.resources.dll, no luck. In Program.cs, before Run is called, I have
Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE");
IF, I only include the MainForm like
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\AL" /t:lib /embed:ReportViewer.MainForm.de-DE.resources /culture:de-DE /out:ReportViewer.resources.dll /template:../../../Output/ReportViewer/bin/Debug/ReportViewer.exe /keyfile:../MySnKey.snk
The appropriate resources are displayed.
This is quite confusing to me. If I add the .resx files to the solution, and compile, the output dll works correctly, but we are trying to avoid having to bring these satellite translations into the solution.
No errors are generated and the files are created so I'm lost as to what I'm not doing.
Any help is greatly appreciated. I compared the differences between the output dll when adding the files to the solution to the output file when running AL.exe and they both contain all the translations.
EDIT to include solution since I can't answer the question
Apparently I got confused with the embed option and it's usage. To properly use the AL.exe utility, I had to use:
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" Resources.de-DE.resx ReportViewer.Properties.Resources.de-DE.resources
Notice above that the Properties namespace is added. I had not done that before.
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" MainForm.de-DE.resx ReportViewer.MainForm.de-DE.resources
Notice that no Properties namespace is added since MainForm is Simply in the ReportViewer namespace.
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\AL"
/t:lib
/embed:ReportViewer.Properties.Resources.de-DE.resources
/embed:ReportViewer.MainForm.de-DE.resources
/culture:de-DE /out:ReportViewer.resources.dll /template:../../../Output/ReportViewer/bin/Debug/ReportViewer.exe /keyfile:../MySnKey.snk
Notice that there are multiple /embed items in this line. I was using the comma, which renames the internals and is not what I wanted. Providing a space between the files gives a (seemingly) unrelated error. See http://ondotnet.com/pub/a/dotnet/2002/10/14/local2.htm?page=2 for a great article.
For completeness, another way of writing this script would be
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" Resources.de-DE.resx
notice that no renaming is done here, the output is simply Resources.de-DE.resources
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ResGen" MainForm.de-DE.resx
notice that no renaming is done here, the output is simply MainForm.de-DE.resources
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\AL" /t:lib
/embed:Resources.de-DE.resources,ReportViewer.Properties.Resources.de-DE.resources
/embed:MainForm.de-DE.resources,ReportViewer.MainForm.de-DE.resources
/culture:de-DE
/out:ReportViewer.resources.dll /template:../../../Output/ReportViewer/bin/Debug/ReportViewer.exe /keyfile:../MySnKey.snk
Notice that the renaming is done following the comma in the embed option. The first argument is the file name (the .resources file) and after the comma is the fully qualified name (namespace.class.xx-XX.resources).
Answered in the post before I knew I could answer it here.