I'm using a java method to download via agent my multipage dashboard to server file system. When I open the downloaded file I get an error "Excel found unreadable contente in "test.xlsx". Do you want to recover the contents of this workbook? If you trust the source of this workboos, click Yes."
When I click on Yes button, I have a warning "Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded."
Data are perfect, nothing is lost, but file is delivered to end users and I can't let it so.
I've tried the same on another environment, where OBIEE 12 is placed, and unfortunately I encounter the same trouble.
I really don't know what to do. We have installed the patch "11.1.1.7.181016" that promises to fix java security trouble in creating the excel file, but with fully unsuccess.
Any suggestion would be great and precious.
Thank you very much.
There's a reason that 11g is outdated and has been replaced with 12c which itself is already on the way out and being replaces by OAS.
The ancient versions have issues that aren't fixed anymore and something that came out in 2013 is expected to not work anymore with other modern software at some point.
It's way beyond time for you to upgrade. And fast. The longer you wait the more problems you incur.
Update: If the bundle patch and the one-off patch 22934699 don't solve the issue then you will be stuck with it.
Alternatively you can switch to CSV for the export since looking at this question here and your other one all you're doing is data dumping.
I have links to 2 SharePoint sites (different servers) and when I click on the menu option "Edit in Report Builder" on one site it does not load as supposed to the other. I get a dialog that has a show details button on it which when clicked opens a log file. The log file says:
...
Activation of <path>\ReportBuilder_3_0_0_0.application resulted in exception. Following failure messages were detected:
System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
+ Downloading file:///<path>/RptBuilder_3/MSReportBuilder.exe.manifest did not succeed.
...
Any ideas on how to get this to work?
All I know is that I designed the ones on the site that works using Report Builder 12.0. If I go by the error above does this mean report builder 3.0 and so not backward compatible?
I have also tried the clear cache option but that does not work for me either, i.e.:
Open command window
Type: cd C:\Windows\System32
Type: rundll32 dfshim CleanOnlineAppCache
It seems their is an issue between servers that I cannot put my finger on. This is not the ideal solution but simply a workaround.
Goto the following folder C:\Users\[username]\AppData\Local\Apps\2.0
Delete all contents (this is the cached files)
Reopen report
The problem with this temporary solution is works for one server only so I have to repeat each time to switch between the 2 - very annoying.
If someone has a more permanent solution please let me know.
tl;dr: How to modify the .csproj file during publishing with ClickOnce while executing pre-build events?
Long:
I'm using TFS hosted by Microsoft for version control of my solution.
When publishing with ClickOnce, I get the latest revision number + 1 without problems. I also can successfully write the new version number into the .csproj file outside my build-process.
The problem is, that the .csproj file doesn't get updated during the build process - it might be in a write-lock. I get a notification inside Notepad++ about the modification of the file, but the file still contains the old version and VS didn't notice any changes.
The only solution by now I found to resolve this issue:
Move the revision update into the post-build events and add 2 instead of one to the actual revision number. Unfortunately this would cause that revision number would be out of date whenever other developers check-in code.
Ok, strike that... :(.
After some more diffing, you'll need to override the GenerateApplicationManifest target to get this to work. That target doesn't use a *DependsUpon propertygroup, so it's harder to overwrite. The whole flow is defined in the Microsoft.Common.Targets file which you can find in the %windir%\Microsoft.NET\Framework{cpu}\{version} folder.
See also:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3a94df52-74c1-4fca-a830-ab530ec49207/use-msbuild-to-create-clickonce-app-files-in-alternate-location
We are using SVN for version control of code from notes databases. These databases contains a lot of ls/js/java code. For js/java code it works fine.
The problem is with ls libraries. There are at least a hundred of them and they are interconnected. Sometimes if developer submits a ls code change to SVN and then someone else tries to update his copy of database he is getting a lot of syntax errors in notes client. The changed library does not even open properly in old editor and ls code is stored inside field oddly named $ScriptLib_error.
This problem goes away after the developer removes assosiation with on-disk project and than connects the db back to it.
Has anybody else encountered this problem? Are there any feasible solutions?
What version of Designer are you using? There were many fixes for source control issues (in particular in the area of LS script lib import) added to 853 Fix Pack 2. If you are not on that fix pack please upgrade to it.
In my project I have a class that is inherited by many other classes. We'll call it ClassBase.
public class ClassInheritFromBase : ClassBase
When ClassBase is being inherited, ReSharper throws an "Ambiguous reference" warning on the ClassBase, and anything inside the new class that inherited from ClassBase does not have IntelliSense and gets warnings that it cannot find it.
The project compiles and runs fine.
If I change the namespace ClassBase is in and then change the inheriting classes, they find it fine and ReSharper has no problem, IntelliSense works ... until it is compiled. After the compile it goes back to having the ambiguous reference warnings and everything else.
Has this been seen before and how can it be fixed? I saw an entry in JetBrains bug tracking for an issue just like this, but they closed it as unable to reproduce.
For those who still have a problem with this, (I still get it from time to time) here's the steps I did to get rid of the ambiguous reference warning in ReSharper.
First I went to all my class libraries and made sure that all references to my other class libraries had the Copy Local property set to false.
In the project where I actually got the ambiguous reference warning, I went to my bin catalog and deleted all .dll and .pdb files for all the libraries that had their own project.
After a new build, or in my case "update reference" on the .dll files in VS, the errors from Resharper were gone.
I'm using Resharper 5.1 in Visual Studio 2008 with only a reference to the dlls I'm using which is why I had to "update reference"
I'm using VS 2012 and ReSharper 7 and sometimes I found the same behavior. These are the steps that worked for me:
Clean Solution
Close Visual Studio
Go to the root folder of your solution and find a folder called _ReSharper.[Name of your solution] and delete it.
Go back to Visual Studio, open up your solution the folder gets recreated and no more "ambiguous reference" errors after that.
I've seen this bug in ReSharper 4.1. It happens when the base class is in the App_Code directory. I don't know how to fix it; it is very annoying, but the code still compiles though.
You may really have an ambiguous reference. In the project where the ambiguous reference error occurs, make sure to check in your project references. You might have the same reference twice but scoped through different namespaces. In my case there were two, but with different paths (example):
XXX.YYY.ZZZ.myassembly
ZZZ.myassembly
Make sure you don't have this kind of thing in your references.
This is a bug in ReSharper 4.1 and is fixed in one of the later nightly builds.
Download the last nightly build at
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.0+Nightly+Builds.
ReSharper -> Options -> General: Click # Clear Caches # button.
For me it was a matter of me not using the solution folder for caches. Changing it from the TEMP location to in the solution solved my problem.
I deleted the _ReSharper.SolutionName folder found in the root of my solution and restarted.
I was using Visual Studio 2010 with ReSharper 5.1... Clearing the cache DID NOT help (ReSharper -> menu Options -> General -> #Clear Cache#).
With R# 2019.2.3 and using the new SDK .csproj format, which splits references between .NET references, NUGET packages, and project dependencies, there is a tendency for R# to still add a project reference under Assemblies, even when there is already a project reference under Dependencies. This results in the ambiguity error but can be hard to notice since the reference is in two separate places. Look for any project references that appear under Assemblies and remove them.
I was experiencing the same problem with references to C# classes in the AppCode folder.
I resolved this by upgrading my ReSharper to version 4.5 (from version 4.1).
It was a very simple upgrade, I just had to get the latest version from the JetBrains website (http://www.jetbrains.com/resharper/download/) and run it.
I did not have to uninstall the previous version (v4.1).
I did not have to re-enter my existing licence key.
All references are now recognised correctly and I can naviage to the classes as expected.
I encountered the same problem. The issue I had was caused by a custom build provider (from an open source library I'm using called PageMethods) and the fact that all my .aspx pages inherit from a BasePage class which lives in the App_Code folder.
I couldn't get any build of ReSharper to work with my project (4.1.933, 4.1.943 (latest) or 4.5). The fix in the latest ReSharper build fixes the "Ambiguous Reference" problem, but breaks the custom build provider.
The only way I could get both the build provider and base classes to work with ReSharper was to put the Base Classes into a separate class library.
The following are the logged Jira bugs that seem to relate to this issue:
False "Ambiguous reference" for
symbols from App_Code
Custom build provider may generate partial
class with second part residing in
app_code
I had same problem with ReSharper 5.1 and solved it by restarting Visual Studio 2010.
Using VS 2013 Premium & Resharper 8.1, and was getting this problem on an ASP.Net project.
The solution that worked for me:
Do a clean Solution.
Open references for the offending project
On each reference that refers to another project in the solution, set Copy Local = false.
Attempt a Rebuild Solution. You will likely get unresolved reference errors - that's normal.
Set each reference back to Copy Local = true (where appropriate)
In VS2022, simply cleaning the solution resolved the errors for me.