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?
Related
I made a project in VS 2022 using vb.net. It worked fine when I ran it from VS (Debug x86 local machine). I published it and it produced a msix upload file with no errors or problems. I then copied the code, xaml and assets to another project with a slightly different name. I ran it from VS and it ran fine, like the original I had copied from. When I published the second (remember, identical copy), it produced hundreds of errors mostly about file names that are the same but sizes are different. I reloaded VS and published again with no other change. This time it produced hundreds of errors of the "System.void not defined" kind, every line of code was an error. It is difficult for me to believe that this is not an error in VS because I did exactly the same thing and got different results. Any thoughs or solutions please?
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.
please help my umbraco site when i try to login to backend comes up Server Error in '/' Application i attached a screen grab below.
I believe this is due to a conflict with something in your binary folder. All the searching I did on this error revealed a common link to a conflict with certain versions of Umbraco VS Contour.
The most common suggestion is to rename the Umbraco.Forms.Core.Providers.V7.dll file in your bin directory.
If this works, you need to look into which version of Contour you should be using for the version of Umbraco you have to see if there is a conflict there.
If that doesn't work, you might want to look at whichever packages you've installed lately and start removing their DLLs.
Worse comes to worse, rename your bin folder, bring in a fresh one for the version of Umbraco you're using, and then bring the DLLs from your renamed bin folder until you can narrow down which one it is that's causing your grief.
I hope that helps!
Im trying to use this http://www.devart.com/dotconnect/mysql/ with Indusoft Web Studio to connect from Windows CE to a MySQL database as its the only solution Ive found. The connection works (from what I see in the logs) but then a error message saying "License not found" pops up. Besides having terrible support, Devart for some odd reason does not understand Im using another IDE besides Visual Studio to compile this project. They keep telling me I need to add the resource to the project when IWS has nothing like this.
I tried to decompile the DLL but I cannot find a method to jump pass the "License not found" message.
Has anyone got this to work with a already complied program and just put the DLL in the same folder as their exe?
Ive tried their .NET Compact Framework complier as well but it did not work either. Their support is like I mentioned terrible. One of (if not the) the worst Ive had to deal with in YEARS.
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.