Adobe Community: RSL Error 1001

Currently Being Moderated

RSL Error 1001

Jan 31, 2008 3:44 PM

Flex Error #1001: Digest mismatch with RSL framework_3.0.189825.swf. Redeploy the matching RSL or relink your application with the matching library.

Hello good people,

I have tried fixing this according to the following URL's instructions: http://www.duzengqiang.com/blog/article.asp?id=681 but it's either not doing it or I keep scewing it up.

I have also read: http://livedocs.adobe.com/labs/flex3/html/help.html?content=rsl_07.htm l and it doesn't look like I'm screwing it up, but I could me missing something. The real issue is that I tried to show this at my customer's location and now no matter what I do, I can't seem to either get rid of the files that are in the browser cache or it just doesn't work. It only does it when deployed to the server. It never happens on my development machines.

I don't have a computer here that it doesn't work on, even my wife's machine runs it just fine and she doesn't have a development environment, so I'm a little confused as to how to handle this.

If someone has a ready answer i would appreciate it. If you need to view the site to experience the issue then send me a private message on this forum and I'll send you the link.

Thanks,

21761 Views 32 Replies Latest reply: Darrell Loverin, Mar 30, 2011 6:01 AM

Replies

Currently Being Moderated

1. Curtis Fisher,

Feb 5, 2008 4:02 PM in reply to Curtis Fisher

Report

Just trying to get this moved up again. I still need an answer to this issue. Thanks...

|
Mark as:
Currently Being Moderated

2. maziak,

Feb 6, 2008 1:55 AM in reply to Curtis Fisher

Report

Hi

We are experiencing the same problem. Also using Flex3B3 with framework_3.0.189825.
Our app runs fine on Windows, but running it from a Linux machine gives us the RSL error.
I have tried every permutation of the fix mentioned in the link:
http://www.duzengqiang.com/blog/article.asp?id=681
... from merge / not merge, include framework / rpc. swf /swz as an RSL
I have tried with downloading the latest SDK (3.0.0.409) and still get the same RSL error on Linux.
I also tested with & without our charting components, even tried moving the framework.swc up in the list above datavisualization.swc as advised in this link (bottom of page):
http://labs.adobe.com/wiki/index.php/Flex_3:Release_Notes
I've also moved the framework.swc to the top of the list.
It all works fine if I merge everything into code, but as soon as I set framework.swc to an RSL I get the error.

We desperately need this fix for linux users of our app that's in production.

Also, is there any chance I may have corrupted my framework.swc after attempting the optimizer / digest processes discussed in the possible fix?

Cheers
Tracy

|
Mark as:
Currently Being Moderated

3. Curtis Fisher,

Feb 6, 2008 8:58 AM in reply to Curtis Fisher

Report

Come on sombody, help us out. This too may happen to others when they deploy. It doesn't occur if you run it on the development machine.

|
Mark as:
Currently Being Moderated

4. Darrell Loverin,

Feb 6, 2008 10:52 AM in reply to Curtis Fisher

Report

One thing to try to trouble shoot the issue on Windows is to run the application with a Flash Player below version 9,0,60. This will force the signed RSL, framework_3.0.189925.swz to be skipped and force the loading of framework_3.0.189825.swf. When you do this are you getting a digest mismatch error? If not, double check the player log to verify the swz file was skipped and you failed over to the swf file. If the swf file works on Windows, then you know the digest is correct and it's a Linux issue. The only platform issue I'm aware of is that the Player does not support 64-bit Suse.

|
Mark as:
Currently Being Moderated

5. Curtis Fisher,

Feb 6, 2008 11:45 AM in reply to Curtis Fisher

Report

Thank you very much Darrell, the issue is that the Plugin 9,0,45,0 was installed. I needed to upgrade to 9,0,115,0. I predict this is an error that most users will not be able to recover from without a high degree of mistrust with Flash.

If the community begins releasing applications compilied with 3.0, and with all the 9.0.x.x plugins out there, if there is no prompt other than this RSL issue popping up, it will create a negative stir that many users will carry on about for far too long. No doubt I'll hear about it for weeks after deployment, and I don't have the bandwidth to deal with it.

I confess that the simple is usually the most overlooked, but unless there is something we can do with the html wrapper for browser sniffing the .x version on the final 3.0 Gold release (I know it can be done, I'm thinking I shouldn't have to do it!) , this will give me concern for deploying my almost completed application out to 1000's of internet users.

|
Mark as:
Currently Being Moderated

6. Darrell Loverin,

Feb 6, 2008 12:04 PM in reply to Curtis Fisher

Report

Flayer Player 9,0,45 should be fine. You should NOT need to install Flash Player 9,0,115,0 to load unsigned RSLs (swf files). Version 9,0,115,0 is only needed to load signed RSLs (swz files).

If upgrading to Player 9,0,115,0 solved your problems on Linux then that means you are now loading the signed RSLs and not having to deal with the unsigned RSL that was failing before. I suspect the framework_3.0.189825.swf deployed on the server is does not have correct digest, but I would really like to know if installing Player 9,0,45 on Windows causes it to display the digest mismatch error or this this problem is isolated to Linux.

|
Mark as:
Currently Being Moderated

7. Curtis Fisher,

Feb 6, 2008 6:15 PM in reply to Curtis Fisher

Report

I'm sorry for the miscommunication on my part Darrell. This is Windows XP, not Linux, and only after I upgraded to 9.0.115.0 did the issue go away. I was assuming that the issue was the same on both operating systems since it only began after i installed the latest 3.0 beta, compiled and redeployed. I really don't know all the details of signed and unsigned swf's, swz's and I haven't read up on the differences between .45 and .115.

If this is an issue because signed files are now being loaded into the player for beta phase III, where in beta 3 phase II (I can't think of the actual version) they weren't, AND the only error that shows between the two players is the RSL Error, then there will be problems with users who are running an earlier versoin of the player. Take a look at the thread on the subject from a FLEX Team Developer, Mac: http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=7 2&amp;catid=651&amp;threadid=1335562&amp;enterthread=y

Anyway, sorry about the misunderstanding. Try upgrading and see if it goes away. Let us know if it doesn't fix it. We're coming down to the wire and I for one, don't need these kind of surprises! I'm hoping the default html has a sniffer that gets the user to download a new player. I don't know what edfrk from the other post will do besides push out a new policy to the 10K+ users, but a more better browser sniffer will have to be part of the solution.

Thanks again...

|
Mark as:
Currently Being Moderated

8. Darrell Loverin,

Feb 6, 2008 7:07 PM in reply to Curtis Fisher

Report

I also work on the Flex team. I implemented the RSL feature for Flex 3.

Just to be clear, Flash Player 9,0,115,0 is NOT required to avoid the digest mismatch error . I think the problem is either the RSL, framework_3.0.189825.swf, was not created correctly or the framework.swc's digest information was incorrectly changed.

|
Mark as:
Currently Being Moderated

9. Darrell Loverin,

Feb 6, 2008 7:23 PM in reply to maziak

Report

I'm surprised your getting the same RSL failure with 3.0.0.409. That build comes with framework_3.0.0.409.swf in the frameworks/rsls directory of the sdk. Are you using Flex Builder to create the application or the command line?

|
Mark as:
Currently Being Moderated

10. Curtis Fisher,

Feb 6, 2008 7:50 PM in reply to Curtis Fisher

Report

Geez, me offering you advice... That's rich. I use Eclipse and the FLEX build is 3.0.190133. Is this correct? Do I need to look somewhere else for version numbers?

I also tried recreating the library as I stated at the begining of this thread, and it did not make any difference (although I don't know If i did it correctly). I'm really confused now. If there isn't a difference between players concerning the RSL error message, then why did the error go away when I upgraded the player to 9,0,115,0?

Not to be arm waving, but why does Mac state that the ,115, player is necessary to display beta 3 properly? He may be talking about other issues, but this is certainly an issue even if it is brought on by misconfigured libraries. I'm pretty sure I did it correctly because i did it 3 times, but I'm not sure if the instructions were correct in the first place. If it is as you state, a library issue, then can someone post an explicit set of instructions for resolution (step 1, step 2, and go slow...) so that we don't have to find a solution on a Chinese web site?

Thanks for your patience. I appreciate your help with this.

|
Mark as:
Currently Being Moderated

11. maziak,

Feb 7, 2008 12:43 AM in reply to Darrell Loverin

Report

Hi Darrell

I did this test as you suggested, from Windows, running our app with Flash Player 9.0.16 installed.
We got the RSL error:
Flex Error #1001: Digest mismatch with RSL framework_3.0.189825.swf. Redeploy the matching RSL or relink your application with the matching library.

What does this mean? Is it a Flex issue, is it a library issue within our application? Is there any solution?

Cheers
Tracy

|
Mark as:
Currently Being Moderated

12. Curtis Fisher,

Feb 7, 2008 7:21 AM in reply to Curtis Fisher

Report

Darrell,

I just backed out of ,115, and used the archives of Flash player to load ,45,. The RSL error appeared after 50% showed loaded on the progress bar.

I then upgraded to ,47, and the error appeared immediately without any progress bar load showing. The PG bar showed up at the same time as the error.

I then upgraded to ,115, and the site loaded without errors.

Tracy, why don't you upgrade and see if you get the same results?

Darrell, I can give you full access to my linux server if this will help you. You can use an FTP client to pull the files down and examine them. Just send me an email at -- curtis dot fisher at procontent dot net --- and I'll create a temp account for you.

Thank you,

|
Mark as:
Currently Being Moderated

13. Darrell Loverin,

Feb 7, 2008 8:26 AM in reply to Curtis Fisher

Report

Curtis and Tracy,

You both seem to be having the same problem. I think you are both using Flex Builder. Note that when you upgrade Flex Builder you will get a new sdk build. The RSLs of a new sdk build will change so you will need to edit your existing project properties for the Flex Build Path so the RSL URLs for framework.swc match the new rsls that are in sdk directory. Please see the tutorial link below for an example of how to modify RSL information in Flex Builder.

It sound like you are using sdk 3.0.189925 because the RSL signed by Adobe, framework_3.0.189825.swz, is loading correctly when you use a Player that knows how to load signed RSLs (version 9,0,115,0 and higher). If you are not using sdk 3.0.189925 then disregard the rest of my instructions here. The solution is to fix either framework_3.0.189825.swf (may not be created correctly) or framework.swc (may have the wrong digest).

First let's verify framework.swc. framework.swc contains a file called catalog.xml. In catalog.xml there is a piece of xml that contains the expected digest of framework_3.0.189825.swf. See the attached code for it should look like. If your catalog.xml contains the same digests, then your framework.swc is correct. If it is not correct then get another copy of the flex3 beta3 sdk (version 3.0.189825) replace framework.swc.

Now to framework_3.0.189825.swf. I have created one that has the correct digest. Send me your email address and I will send it to you. If both of these are correct there should be no digest errors.

See this tutorial

|
Mark as:
Currently Being Moderated

14. Curtis Fisher,

Feb 7, 2008 3:40 PM in reply to Curtis Fisher

Report

Okay Darrell,

Your file worked. I was able to run with ,45, after uploading it to the server. I believe I understand why this was happening. You can tell me if I’m wrong, if it matters. Below version ,115, the player RSL’s are not signed and the player loads the swc file, not the swz file.

This became apparent to me when I saw that on the FLEX Build Path-->Library Path Tab, there existed a build path library of:

framework.swc.

Expanding this library revealed an RSL URL property with the signed library -- framework_3.0.189825.swz – as the value.
Underneath the RSL URL as an attached property is listed the Failover RSL URL with a value of -- framework_3.0.189825.swf --.

I’m a simple man, so I’ll just put it this way… When the player can’t make sense of an swz file because it can’t load signed files, it looks for the swf file. Since the swf is not signed, it has a digest that links it with the application to provide security protection. For some reason the framework_3.0.189825.swf library that came with the sdk and by default was being used by my application was not linked properly. By the way, this happened on a new install to a virgin machine.

Okay, I used the ant file, and had to modify it to get it to work. For one, it’s not well formed, missing a /java end tag. Second, and this is what I need you to verify for me, I don’t know why the line

OpenElementTag--arg line="--digest.rsl-file @{rsl-dir}/@{swc-name}.swf --digest.swc-path @{swc-dir}/@{swc-name}.swc" --CloseElementTag

would work because the swc-name needs to be framework in order for the optimizer to output it with the correct name (at least to stay within the naming conventions we are using). So what happens is the argument line --digest.rsl-file @{rsl-dir}/@{swc-name}.swf cannot find the swf that was created by the optimizer since the swc-name variable does not match the name that was created with the optimizer (--output '@{rsl-dir}/@{swc-name}_3.0.${build.number}.swf' = framework_3.0.189825.swf). I tried to use the ${build.number} again, but it must be getting assigned from the metadata of the optimizer, I can’t quite figure it out. I finally got it to work, by hard coding the name in like so…

OpenElementTag--arg line="--digest.rsl-file @{rsl-dir}/framework_3.0.189825.swf --digest.swc-path @{swc-dir}/@{swc-name}.swc"--CloseElementTag

I’ll get back into my Ant documentation and see if I can figure out how to code for that.

I am attaching the build file I created. Place it in the root\sdks\3.0.0\frameworks directory and it should work right out of the box. It is setup to use the standard directories. This is a windows installation, but it should work on Linux.

I hope we can put this to rest. Please correct me if I have misunderstood what is happening. You have my heartfelt thanks for your assistance and if you're at the 360 conference, let me know and I'll buy you a draft.

Sincerely,

|
Mark as:
Currently Being Moderated

15. Darrell Loverin,

Feb 7, 2008 8:06 PM in reply to Curtis Fisher

Report

Your right about how signed RSLs will failover to unsigned RSLs. Both the signed and unsigned RSLs have a digests for security. The problem with framework_3.0.189825.swf is that it was not packaged in the sdk when it should of been and you ended up with a bad one (either thru your efforts to create one or Flex Builder created an unoptimized one for you). I'm sorry this error has caused you so much grief but I'm glad you kept working with me to get to the bottom of the problem. The missing RSL was a one time mistake and shouldn't happen again.

In regards to the Ant task. Your right the output of the optimizer does not match the input of the digest tool. My mistake, sorry about that. To fix the problem I would change the --output argument of the optimizer by removing the _3.0.${build.number} from the name. This change would make the --output argument look like this --output '@{rsl-dir}/@{swc-name}.swf'.

The ant task in the tutorial was not supposed to add the build number to RSLs like the ones in the SDK. It was for folks to roll their own RSLs. Since you were wondering about the where the {build.number} comes from, it's defined as an argument to ant on the command line.

>ant -Dbuild.number=189825

|
Mark as:
Currently Being Moderated

16. xchg.ca,

Feb 15, 2008 3:24 PM in reply to Curtis Fisher

Report

So what is the solution for Linux?
Mozilla 2.0.0.12 and Flash Player 9.0.115.0 gives me #1001 Error, while all windows machines works well. Note all my SWFs build under windows machine not Linux.

|
Mark as:
Currently Being Moderated

17. Curtis Fisher,

Feb 15, 2008 3:52 PM in reply to Curtis Fisher

Report

It's the same problem on either type of machine. The library's you are using were hosed.
---------------------------------------------------------------------- -------------------------
The problem with framework_3.0.189825.swf is that it was not packaged in the sdk when it should of been and you ended up with a bad one (either thru your efforts to create one or Flex Builder created an unoptimized one for you).
--------------------------------------------------------------------- -------------------------

If the ant script won't work for you, send me an private message with your email address and I'll send you the library. You can set the libraries to be included in a single swf file in the library tab under project properties as well.

Hope this helps...

|
Mark as:
Currently Being Moderated

18. xchg.ca,

Feb 19, 2008 8:33 AM in reply to Curtis Fisher

Report

quote:

Originally posted by: cxf02
It's the same problem on either type of machine. The library's you are using were hosed.
---------------------------------------------------------------------- -------------------------
The problem with framework_3.0.189825.swf is that it was not packaged in the sdk when it should of been and you ended up with a bad one (either thru your efforts to create one or Flex Builder created an unoptimized one for you).
---------------------------------------------------------------------- ------------------------
Hope this helps...

Foe me It works OK at windows machines, not Ok at Linux..... And what about ant script? how it suppose to help me?

|
Mark as:
Currently Being Moderated

19. xchg.ca,

Feb 21, 2008 12:38 PM in reply to Curtis Fisher

Report

I've manages to execute posted script, which generated framework.swf for me, because I used Like argument framework.swc.

At the end is said: that digest was updated IN framework.swc in my Abode Flex folder!? Is it ok?
What happened if I will deploy compiled SWF under Linux environment? Should I also move updated framework.swc there?

|
Mark as:
Currently Being Moderated

20. Darrell Loverin,

Feb 21, 2008 12:55 PM in reply to xchg.ca

Report

It is ok to update the digest in framework.swc, although you should have not needed to. The digest should have been correct, you were just using a framework_3.0.189825.swf that did not match the digest.

First I would try deploying the framework_3.0.189825.swf you created with the script and see it that fixes the problem. If that doesn't work then I recommend you recompile your application, to pick up the new digest in case it changed, and then redeploy the application.

|
Mark as:
Currently Being Moderated

21. SureshVytla,

Sep 9, 2008 12:00 AM in reply to Curtis Fisher

Report

Hi,

I am looking help on the same error.

"Flex Error #1001: Digest mismatch with RSL framework_3.0.0.477.swf. Redeploy the matching RSL or relink your application with the matching library"

I have Flex Builder 3.0, compiled using the frame work library path
as RSL. Deployed the swfs and swz on the same location.

Its is working in only one machine and not working other machines.

Environment details:
Flash Player 9,0,124,0
IE 6 & 7.

Even I re-complied and deployed, its not working out.

Can anyone tell what should we do with this?

Thanks,
Suresh

|
Mark as:
Currently Being Moderated

22. SureshVytla,

Sep 9, 2008 3:27 AM in reply to Curtis Fisher

Report

Hi All,

I tried with Flex Builder 3.0.1 and Flex SdK 3.1, but still issue exists. Can any one Suggest how to resolve this issue.

Error Message

"Flex Error #1001: Digest mismatch with RSL framework_3.1.0.2710.swf"

Thanks,
Suresh

|
Mark as:
Currently Being Moderated

23. Darrell Loverin,

Sep 9, 2008 9:14 AM in reply to SureshVytla

Report

Does the application run from FlexBuilder without a problem?

Do you have more than one FlexBuilder project using RSLs that are deployed to the same location? I ask because this means the framework RSL will be copied from multiple projects to the same location. Due to a problem updating RSL project data when the Flex SDK is changed from within FlexBuilder, you could end up with RSLs with the same name but from different releases. The easiest way to fix that problem is to edit the RSL project data for framework.swc. Remove the existing entries and re-add them.

|
Mark as:
Currently Being Moderated

24. SureshVytla,

Sep 9, 2008 9:35 AM in reply to Curtis Fisher

Report

Hi Loverin,

I have only one project that uses RSL in the FlexBuilder. All the swf that are taken from the sam flex project. When I upgraded to Flex Builder 3.0.1, removed the old entries of RSL from framework.swc and re-entered.

Thanks,
Suresh

|
Mark as:
Currently Being Moderated

25. Darrell Loverin,

Sep 9, 2008 10:07 AM in reply to Curtis Fisher

Report

OK. So you have only one project. You can run the application successfully from FlexBuilder but when you deploy the project to your server and run it you get a digest mismatch error. Is that correct?

|
Mark as:
Currently Being Moderated

26. SureshVytla,

Sep 9, 2008 10:32 PM in reply to Curtis Fisher

Report

Yes, I can run the application successfully from the FlexBuilder.
When I deployed on the server (OS is Linux) I get the digest mismatch error.

Thanks,
Suresh

|
Mark as:
Currently Being Moderated

27. Darrell Loverin,

Sep 10, 2008 6:46 AM in reply to SureshVytla

Report

In the way of a brief background, the application swf when compiled to use RSLs, gets a digest from framework.swc that matches the digest of the RSLs for framework.swc. So an application that is compiled against a given SDK version, must also use the RSLs from the same version or the digests won't match.

Here's some things to try to trouble shoot the problem. From your first email I'm assuming you are having the problem on Windows using IE.

1. Clear the Flash Player cache on the machine where the RSL is working. Doing so will force the Player to read the RSLs and verify the digest instead of getting the RSL from the cache.
Remove all the RSLs from the Flash Player cache by using the Global Storage Settings panel ( http://www.macromedia.com/support/documentation/en/flashplayer/help/se ttings_manager03.html) in the Flash Player Settings Manager. Uncheck the option to "Store common Flash components to reduce download times" and click the Confirm button. Then click the "Store common Flash components to reduce download times" check box again to re-enable the cache.

2. Copy the application swf and RSLs from the FlexBuilder bin-debug directory directly to the server.
3. File compare the copied files to make sure they are the same.

If the application works on FlexBuilder and you copy the same files to the server it should work there as well.

|
Mark as:
Currently Being Moderated

28. SureshVytla,

Sep 10, 2008 9:58 AM in reply to Curtis Fisher

Report

Hi Loverin,

Thanks for your detailed reply. I could probably mentioned the steps that I have done. Anyhow here I am mentioning the steps what I followed.

As you said I changed the compiler setting to SDK 3.1 with Flex Builder 3.0.1. So the RSL changes to 3.1.0.2710.

I was used the Global Storage Settings to UnCheck the "Store Common Flash components" and confirmed and then checked option back.

I was cleanly build the swfs and copied on the server. I have 5 swfs, all are working fine from the Flex Builder.
But no luck.

I try to access the application from others machine those never accessed the application before. I got the same digest error message.

Currenly I am going with merged code option.

Once again thanks for your help.

Thanks,
Suresh

|
Mark as:
Currently Being Moderated

29. Andy_1001,

Apr 28, 2010 7:32 AM in reply to SureshVytla

Report

I'm getting this error, though it references framework 3.2.0.3958, as you can see below. I haven't had any problems with the application in question, and it works fine for some users. Some users, however, are getting this error. The application used to work for them (including after my last deployment) but suddenly some of them get this error. I'm using the same version of Flash Player as the users with the problem (10,0,45,2 ). The only difference between users with and without the problem seems to be the network that they're on.

Does anyone have idea how some users could suddenly start getting this error, or how it might be possible that being on a specific LAN could cause it?

Flex Error #1001: Digest mismatch with RSL http://gis.chesapeakebay.net/baybarometer/framework_3.2.0.3958.swf.
Redeploy the matching RSL or relink your application with the matching library.

Thanks!

|
Mark as:
Currently Being Moderated

30. Greyswandir,

Dec 16, 2010 11:51 PM in reply to Curtis Fisher

Report

There are 2 ways to fix this problem:

1) In project's properties->Flex Build Path change the combo to "Use SDK default". This way encreases the size of your *.swf file but it will be available from every PC.

2) I've found the solution there: http://viveklakhanpal.wordpress.com/2009/02/13/failed-to-load-rsl-erro r-2032/, so you need to update your webserver to recognise file extension (*.swz) or mime-type (application/x-shockwave-flash).

|
Mark as:
Currently Being Moderated

31. FolakemiFapohunda,

Mar 30, 2011 2:20 AM in reply to Darrell Loverin

Report

Hi Darrell- I'm currently experiencing same problem locally with our flex sdk 3.4.0.9271 application deployed on tomcat:

Flex Error #1001: Digest mismatch with RSL http://10.129.142.158:8080/paragon2/flex/framework_3.4.0.9271.swf. Redeploy the matching RSL or relink your application with the matching library.

Previously i was able to run the application successfully with same flash player 10.2.153 on IE without this error but i noticed the issue started around the time i installed flash player debugger to run flexunits and even uninstalling it, clearing the player cache doesnt fix the problem as well as perfoming the instructions you earlier provided on this thread also reinstalled flex sdk 3.4 to no avail. Other developers are able to access the application sucessfully deployed on my localhost.

Please i would appreciate if you can urgently help as i have to test changes made to the application for production. I can send a you a copy of my framework_3.4.0.9271.swf and framework_3.4.0.9271.swz privately to confirm that the digests are valid or not (i didnt make any changes to).

Thanks,
Folakemi

|
Mark as:
Currently Being Moderated

32. Darrell Loverin,

Mar 30, 2011 6:01 AM in reply to FolakemiFapohunda

Report

Here's what I would try for troubleshooting:

1. Confirm that other developers who can run the application have cleared their flash player and browser caches.
2. It could be that your framework_3.4.0.9271.swf and framework_3.4.0.9271.swz match up, but you may be compiling your application with a different version of the library than you expect.

First, I would verify that I was compiling with the correct framework.swc and getting the right digest in the application. If that was correct I would then verify the RSLs that are deployed match the digest in the application.

Verifying the digest in the application:

Compile your application with "-keep". In the "generated" folder there will be a file named digest temp.swf -swc-path temp.swc

The digest tool calculates the digest of temp.swf and updates temp.swc with the new digest. Open temp.swc and look at the unsigned digest of temp.swf. Does it match the digest of the application?

Please reply with your results.

-Darrell

|
Mark as: