I have a Dundas chart being used in a SSRS Report with some custom code in the PostInitilize Event that looks something like this:
foreach(CustomLabel curLabel in chartObj.ChartAreas[0].AxisY.CustomLabels)
{
curLabel.GridTick = GridTick.None;
curLabel.Text = Convert.ToString(Convert.ToInt32(curLabel.Text) - 10);
}
Its takes each axis label and reduces the value by 10.
This works great on my machine, it even works fine on the production server in report viewer. But when this report is run as a subscription, the code fails to run. The report generates just fine but the axis labels are unchanged.
How could this be happening? What is different about running a report as a subscription?
After much searching, I have discovered the solution to this.
The problem is the version of Dundas on my development machine was slightly newer to the one in production (2.2 v 2.1). This causes the code assembly not to be trusted I guess. (but only when running unattended?)
The obvious solution is to upgrade the server, or downgrade my development machine so the version numbers to match. I couldn't touch the installation on the server, and downgrading my own machine would take to long and be annoying. But there is another solution.
Find a machine with the correct version of dundas installed, open the report in Visual Studio, open the code, make a superficial (like adding a blank line, or a comment) then compile the code. This report will now contain the 'correct' assembly. Deploy this to the server, and everything should work.
Related
I get this error some 23 times when publishing the website. There are no issues with compilation and testing. I know someone is going to have the urge to say "remove the duplicate reference from the web.config" but that's not the problem here. This is a project started in 2008 and the use of ReportViewer predates the code being added to our git repository (which in turn predated me working on it) so I know that nothing is technically wrong with the code. In fact, until last week, it published just fine. What changed? I finally got a newer, faster computer. The client wanted one line removed. I put the code on the new computer, removed the offending line, built, tested. All is ok. Then I went to publish and got the ReportViewer error. I'm working with a byte-for-byte copy of the project on the old computer and the only thing that fails is the publish on the new computer.
Clearly something isn't installed on the new computer that's preventing publish, but I don't have a clue what it is. (Or possibly something installed that shouldn't be. The "new" computer was actually in-use by another developer.)
I was grasping at anything for this problem. I got the idea to remove all copies of the ReportViewer DLL from the Microsoft.ReportViewer.WebForms folder. There were 5 different versions. Windows itself balked when I tried to move version 10. That was my clue. It turns out that whoever switched from version 10 to version 12 missed a couple of source files. I updated the reference to version 12 and the problems cleared up.
Now the real mystery is: why did it ever work on the old computer?
Lately I am having some very weird problems and I can't exactly pin out what is causing it.
I've got an Access frontend application which uses SQL Server linked tables. A few days ago I deployed a new ACCDE version which caused some very weird problems.
At one computer I was unable to open a form from the Ribbon (some 21~ ish error can't exactly remember but it was a default open-form error). After some investigation I found out that the problem is caused by an allow additions = false line on the on-open event of the form. This however is very strange since it has always been there. Besides that, at almost every other computer, including mine, it just works fine while the code (and forms, queries, etc.) are exactly the same..
When trying to open the same access file in accdb at that specific computer it does seem to work (opening being done with runtime version).
So as workaround (for the time being) we made sure that that this computer opened the file as accdb while the others (where it did work) opened it as accdde.
Today however it went wrong again but on a different computer and a different issue. Now a completely other form doesn't load it's data (it's empty). Testing it locally it works fine however and testing it yet again on another computer (with also a runtime version) it also opens fine with data in it...
The weird thing is when using an older file (a few application versions back) just works fine but the current one doesn't, at least not on all computers. This makes me believe that the file is corrupted but the weird thing is, why DOES it work on some other computers? If the file would be corrupted you would say that it is causing the issues on all the computers?
So the next thing I thought of was different Access runtime versions. I tested 4 computers (two where everything works fine) and the other 2 have issues.
Computer one (which works fine) is a 32 bit system with Access runtime version 15.0.4841
Computer two (with issues) is a 64 bit system with Access runtime version 15.0.4569
Computer three (also with issues) is a 32 bit system with Access runtime version 15.0.4833
Computer four (my own computer tested against a local db) is a 64 bit system with Access runtime version 15.0.4849
So the computers where the Access file doesn't work all have a lower version than the ones that do work, is it possible that this is causing the problem?? If it is, I still wonder why the older Access application file works on all computers but the current one doesn't..
On a side note:
Also tried to repair the access runtime version on one of the computer where it didn't worked but this had no effect
Doing a Compact & repair on the Access file itself also doesn't have any effect
Well, you plain and simple cannot run an x32 accDE database with the x64 bit runtime – it simply will not work.
And if the runtime versions are different on those target machines then you want to un-install the runtime, and download the latest version. Windows update will NOT update the runtime. With runtime 2010, you had to download + install runtime, and then ALSO download an update to the runtime.
With 2013, then the latest download of the runtime will always include the latest SP updates.
Attempting to run Access with different runtimes will in general be a disaster. And in the case of attempting to use the x64 bit runtime on an application compiled to x32 will not work at all.
I would also before you compile to an accDE check and remove any and all references not required. So references to word, excel or anything else should be removed and late binding should be used.
Regardless, you want to ensure that all computers are using the same runtime version, and this includes the bit size. So in all cases you want to ensure and use the x32 bit runtime, and then ensure that all machines are running the same version/revision of the runtime.
I have a weird problem in an windows phone 8 project (Visual Studio Express for windows phone 8) that Changes to xaml( ex:change visibility of control) don't reflect on App until I rebuild the project and deploy it again to emulator or device.
The changes reflect normally in the design window of visual studio but didn't reflect on the running App.
I did many researches and they didn't help, like:
1- Change "Build and Run" to "always build" when projects are out of date.
2- I checked configuration manager as This post suggests but it was selected.
I have the exact same issue. I have a work around at the moment to save the hassle of rebuilding the solution because rebuilding deletes and re-installs the app and changes any saved settings you've made while debugging. The work around is to switch between configurations. So I'll execute the app in Debug, make some changes, then the next time I execute I change config to Release, and the changes are there.
The difference I can see is when it works I can see the Build Output line which says "Updating the application as the manifest file has changed..." take a few moments to complete. When this issue occurs the output line appears for a split second and so you can tell the incremental deployment hasn't actually been deployed to the device/emulator.
This is a little frustrating so hopefully someone has a real answer. I have other projects on the same machine and they don't have this issue. Just the one project so I don't think its a VS2012 problem.
I've also tried suggestions from other sites saying delete bin and obj folders but that didn't work.
I had the same issue for some of my WP8 Silverlight projects in VS 2013. I couldn't understand why it happened only for some projects but not all, but eventually I found this forum thread. The solution is the following: if the name of your app includes spaces, you definitely need to remove them or replace say with the underscore char. This recipe helped to recover my 'problem' projects.
I also noticed that numbers at the beginning of app name cause the same problem. I solved it by removing numbers from solution and app name.
For the sake of testing, knowing that I am running from Visual Studio would be nice. I could see if the debugger is attached, but that is not sufficient if I am running with CTRL+F5.
Here's how to see if the debugger is attached:
if (Debugger.IsAttached) Foo();
But my question is, I wonder if there is a way to ask if the current app is from the Store. So, I thought about install folder, but they are identical. Then I thought about this:
Windows.ApplicationModel.Package.Current.Id;
But this appears to be completely implemented even for apps that are being debugged. So, I am stumped. Does anyone know if we can determine if the app is from the Store?
While certainly not the most elegant solution and there's probably a better one, you can check Package.Current.InstalledLocation.Path
If you are running a debug build developed on your local machine and not side loaded, you'll have /debug/ in your folder path.
In Windows 10 apps (this also should be available in 8.1), you can check the IsDevelopmentMode property on the current package.
Package.Current.IsDevelopmentMode
That should tell you whether the package was installed in development mode (which I believe is synonymous with 'side-loaded').
See https://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.package.isdevelopmentmode.aspx
for more information.
I would like to Publish my web application and view a report with the Microsoft ReportViewer. Everything works locally but when published I've encountered a troubling number of errors. Finally I seem to have come across one that I cannot fix.
So far I have solved the first 3 problems by...
Installing the Miscrosoft Report
Viewer Redistributable 2008
package on my server.
Changed my "rdlc" file to be "Content" and removed the rdlc
buildProvider in the web.config
file.
Configured the Managed Handler in IIS for the ReportViewer
Finally, the ReportViewer is at least visible and it "seems" to be trying to load the report. BUT Now I'm getting the following error:
[InvalidCastException: Unable to cast
object of type
'Microsoft.Reporting.WebForms.ReportHierarchy'
to type
'Microsoft.Reporting.WebForms.ReportHierarchy'.]
Microsoft.Reporting.WebForms.ReportDataOperation..ctor()
+253 Microsoft.Reporting.WebForms.HttpHandler.GetHandler()
+669 Microsoft.Reporting.WebForms.HttpHandler.ProcessRequest(HttpContext
context) +13
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+181 System.Web.HttpApplication.ExecuteStep(IExecutionStep
step, Boolean& completedSynchronously)
+75
Oh great! Of course you can't cast an object to the type that it already is!!!! Does anybody know how to fix this one?
Thanks,
Justin
Well turns out when I did step 3.
"Configured the Managed Handler in IIS for the ReportViewer"
I registered the wrong one. The system had a v8.0 and a v9.0. 50-50 odds of picking the wrong one and I won.
Let this be a lesson to people who think dialog boxes don't need to be resizable... THEY ALWAYS SHOULD so you can see the content. The version number is not visible in the dropdown you are staring at 2 identical entries to the eye!!!
Anyways... if you encounter this problem check that you're version in Visual Studio matches your Managed Handler on the report server machine.
If you don't have Visual Studio upgraded to SP1, you need to upgrade as per this MSDN thread.
Do you have .Net 3.5 SP1 installed on the server?