I've been struggling with this off and on for two weeks, most of that time having been spent waiting for responses to my support issue. I have the solution, which I will post here in the hopes that it helps the next person who runs into this issue. I'm going to throw in a lot of unnecessary detail to increase the odds of the next guy finding this.
I am working on an MVC5 site, and using the ActiveReports 8 HTML5 viewer to display an IList-bound code-based section report. I have enabled PDF, Word, and Excel exports using the availableExports parameter to the GrapeCity.ActiveReports.Viewer javascript function. The viewer renders properly on the page, and makes the expected call to ActiveReports.ReportSerice.asmx, which returns the information needed to render the report, including the URL to stream the data from. The report displays in the viewer just fine. So far so good.
On my development machine, I can export to PDF, Word, and Excel. When deployed to the test server, however, the Excel export stops working, and the browser just shows a save file dialog attempting to save a file called ActiveReports.ar8?blahblahblah. Digging in with Fiddler, I determined that this is almost exactly the same as the URL returned from the call to the report service above except for a few parameters such as "Command=Export" and "ExportFormat=Xls".
Saving this "file" results in a 0-byte file called ActiveReports.xls. I can simulate this behavior for other export types by removing key dlls such as GrapeCity.ActiveReports.Export.Pdf and then asking for a PDF export, for example. It appears to me that ActiveReports (at least as of version 8.1.414.0) swallows certain server-side errors, such as missing dlls, and returns a 404 error code to the client. I think a 500 error with details about what's missing would be preferable to a generic 404.
This leads me to believe that there is something missing on the test server. Since I have "copy local" set on all the ActiveReports dlls, and I can see that they all successfully deployed to the test server, the missing piece must be something present in the GAC of my local machine, but not on the server.
Using Fiddler, I have determined that the response to the ActiveReports.ar8?blahblahblah URL has a return code of 404. The content-disposition header on the resulting 404 response has been set to "attachment; filename=ActiveReports.xls", but the Content-Type is "text/html" rather than the expected "application/vnd.ms-excel". This tells me that the export made it at least partway through processing before giving up.
What's missing on the server that's preventing Excel exports from completing?
The missing piece of the puzzle is the DocumentFormat.OpenXml.dll, a copy of which can be found in the "C:\Program Files (x86)\Common Files\ComponentOne\ActiveReports 8" folder. Ironically, it alphabetizes right next to all of the GrapeCity.ActiveReports assemblies, but without any indication of which other assemblies use it, you can easily look right past it as I did, figuring it was a dependency of something else in that folder such as the license generator.
Adding a reference to DocumentFormal.OpenXml.dll to the web project, and setting Copy Local to true ensures that the dll gets deployed along with everything else. My Excel exports work just fine now.
I apologize for the inconvenience you were facing. You are right that the 'DocumentFormat.OpenXml.dll' is also required on the server when using Excel export with ActiveReports. I've placed a request for this to be added to the documentation.
Thank you for bringing this to our notice.
Regards
Related
I'm trying to figure out the root cause of a strange TFS error we are seeing in our current instance. It wasn't noticed until after a server move, but I'm not sure if they're directly related, because the error seems to be showing up for check-ins about a week prior to the move, as well as all those following it.
We first noticed the problem when I tried to get latest, and got several errors indicating:
"The downloaded file is corrupt. Please get the file again."
Upon looking into the error, we have noticed that starting as of a single check-in every code update has resulted in files being replaced with the contents of other files, ranging from project files to binary executable files (presumably assembly DLLs), rather than the expected content which is still present on our local development machines.
I don't have admin access to the servers myself, but am looking for ideas on possible causes and/or fixes for our team to investigate.
After weeks of searching, I finally found another mention of this sort of thing happening, along with a solution that appears to have worked.
Clear the Application Tier cache.
MSDN Archived Forums: TFS swapping contents of files
We are creating a SCORM package (zip) and uploading to our Blackboard test instance and if one developer (will call him Bob) creates the zip and uploads then all everything works great. Myself and one other developer have packaged up the zip and uploaded it and a particular js file gets a 404 ("The specified resource was not found, or you do not have permission to access it") error when we try and run the application.
If Bob sends me his zip and I upload it to Blackboard it works fine and if I send Bob my zip and he uploads it then it fails, so I am pretty certain that is is an issue of the zip creation. I have looked at the zips and they look identical in terms of file structure.
3 questions:
Is Blackboard known to have particular problems with zip details? These do look like valid zip files.
Are there logs in Blackboard that describe the unzipping process that Blackboard uses when it installs a new SCORM package?
Is there a way to look at the deployed files/dir structure of a deployed SCORM package?
I am relatively new to Blackboard so if I missed something obvious I apologize.
I don't know any specifics about Blackboard's SCORM handling, but if your ZIP is smaller than 100MB you can test it for free at SCORM Cloud. They have a really great parser that will alert you if there is anything unusual or malfunctioning in your SCORM package. It will also let you inspect the package contents.
If it's just the one file that throws the 404 or 403, I'd check the security settings on the file. If they're too restrictive, the file may be physically present in your ZIP, but blocked from rendering by the server (hence 403) or maybe even blocked in the initial upload by the LMS (hence 404) due to insufficient privileges. I've had this happen a few times, typically on files that I downloaded from the interwebs (esp via Chrome's "Save As" file menu option) or on files I received from others.
If you're on a Mac and not a Terminal/chmod kind of guy, the easiest fix is to apply the containing folder's permissions to all enclosed items. ("Get Info" on the containing folder, then click the lock at the bottom of the Get Info window, then click the cog drop-down menu and select "Apply to enclosed items".)
We discovered that it was a path casing issue; on one of the machines the working copy of the file in question had a mix of upper and lower case in it's name and the script tag that referenced it had an all lower case path. We suspect, but can't be certain, that the server where we are running on received an update that made the http requests path case sensitive. But it may have been that way all along and one of us devs messed up out file names.
I've come across a dodgy file upload on our server. It is an image and the MIME TYPE checks out, though on the server it was also uploaded with the extension .asp and .cer.
On the surface its a photo some weird chinese symbols and the letters asp, though I am sure it is hiding malicious code. I did a google search by image and it came out in a few possibly unsecure directories in some other sites.
This is out of my league to even verify. Out of interest I opened the file in notepad and it has the clear string "Google" which only makes me believe more that it is malicious.
All I need to know is
1- is it malicious?
2-did it run and what did it do?
3- how do i protect against it?
I cant give the link to the actual file on my server since Its been removed, but I can zip and mail it to anyone who wants to take a look.
If anyone has some advise on where to start I would appreciate it.
Heres a link to the same image, which came up on my google search though this one most likely has different code injected
http://www.bakjuweel.be/ShowImage.aspx?img=/upload/fotogalerijen/13/3.asp;.jpg&w=135&h=111
UPDATE
After alot more research I have found that it had a modified header to inject code. I run it through virustotal.com and my suspicious were confirmed. https://www.virustotal.com/en/file/3eac6e45d5923632089b538ca86d576c9994bd25be7940165ec997484d7c6715/analysis/
What it does or whether it executed is still unknown
OK, the file was malicious it contained encoded php, all of which im not sure of there were far too many encoded layers. It created a backdoor that fetched and executed remote code. This file was not detected by any of our antivirus software, what gave it away way was <% eval(. was the only part not encoded.A hacker took advantage of a vunerability in an old version of FCKeditor to add and execute it. I am still looking for a way to prevent it in the future.
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
I've added a couple of lines to a file, let's say it builds to be foo.dll. It's part of more then one dll file, but it's the core dll. What I did was that I added a couple of lines so it should add some log data to the database. It should not affect any other files what so ever.
So i tried to deploy it. We don't have the magical one click deploy, we are just copying the right files to the right place.
So now, since i have a change in foo.dll, i thought for myself that i just could copy foo.dll and the server would be happy.
I was wrong. Browsing the website i now get "Generic Errors", dont know what that is. I've also tried to copy all the new dll files (4 i total) but that did not solve the problem either.
The error it gives are
Http Error 404.0 not found
Module: ISS Web Core
Notification: MapRequestHandler
Handler: Static File
Error Code: 0x80070002
replacing the new foo.dll with the old one solves the problem. and i've tried to restart the webserver. :-(
I asume you have "published" and not just "compiled" your Web?
You also need to take care off the "Solution Configurations": Debug and Release.
In a normal publish process you would change the configuration to release and publish your project into another folder.
After you have done that you just need to collect the desired files and upload them.
Keep in mind that you need the newest version of you web project. Maybe there are some changes online that your local project hasn'T. This would cause such problems.
We don't have the magical one click deploy
Why not? It's not magic, and it's pretty easy to set up. Get any continuous integration software (I would recommend BuildMaster since I am a developer for it and it's free now) and you'll never have this problem again.