This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- InstallShield releasing outdated DLL from Temp. ASP.NET files instead of /bin/Release
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 14, 2012
07:15 AM
InstallShield releasing outdated DLL from Temp. ASP.NET files instead of /bin/Release
Greetings.
We're using .NET v4.0, VS2012 Update 1 and latest version of InstallShield 2012 Spring Limited Edition.
We got scared when noticed that InstallShield doesn't rely on latest built libraries from project output. Instead, it gets the oldest version as possible from*Temporary ASP.NET Files folder! (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files)
Unless we clean up Temporary ASP.NET Files, there is no way for InstallShield to embed the actual latest DLL from project output.
Furthermore, I had two outdated versions of that DLL in*Temporary ASP.NET Files folder, and InstallShield got the oldest one. After I deleted the oldest it got another outdated DLL from there. Finally, I cleaned up*Temporary ASP.NET Files and it got the DLL from Bin/Release (which should be the only and obvious place to get the DLLs from).
Once we cannot rely on a manual procedure of cleaning up*Temporary ASP.NET Files folder, we just don't know what to do.
We hope we don't need to build our own Setup mechanism...
Kindly advise.*
Regards,
Bernardo Ely
We're using .NET v4.0, VS2012 Update 1 and latest version of InstallShield 2012 Spring Limited Edition.
We got scared when noticed that InstallShield doesn't rely on latest built libraries from project output. Instead, it gets the oldest version as possible from*Temporary ASP.NET Files folder! (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files)
Unless we clean up Temporary ASP.NET Files, there is no way for InstallShield to embed the actual latest DLL from project output.
Furthermore, I had two outdated versions of that DLL in*Temporary ASP.NET Files folder, and InstallShield got the oldest one. After I deleted the oldest it got another outdated DLL from there. Finally, I cleaned up*Temporary ASP.NET Files and it got the DLL from Bin/Release (which should be the only and obvious place to get the DLLs from).
Once we cannot rely on a manual procedure of cleaning up*Temporary ASP.NET Files folder, we just don't know what to do.
We hope we don't need to build our own Setup mechanism...
Kindly advise.*
Regards,
Bernardo Ely
(11) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 19, 2012
03:30 AM
I have not seen anything like this? how are verifying that it takes old version? do you have an sample which replicates this?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 27, 2012
09:17 AM
Shekar wrote:
I have not seen anything like this? how are verifying that it takes old version? do you have an sample which replicates this?
Hello Shekar. We verify it's using an old version of the DLL by checking its Modified Date. We can consistently replicate this in our project. I'll try to build a sample app to replicate it.
Thanks,
Bernardo
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2013
08:07 AM
I am having the exact same issue. InstallShield Limited edition is pulling files from the Temporary ASP.Net folders. The interesting thing is my application is NOT an ASP.Net application. It is a winforms application. I do have an ASP.Net application that shares some common dlls. Why is InstallShield pulling from the Temporary ASP.Net location at all???
Have you been able to find any resolution to this?
Have you been able to find any resolution to this?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2013
09:34 AM
do you have any sample which shows this... if you can attach that, i will try to look into this.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2013
08:51 AM
could you please elaborate if you mean that asp.net dependency are not getting detected or are they missing?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 02, 2013
04:20 AM
I am getting this exact same problem. I have multiple wcf IIS projects that reference the dll. I have also a windows service that is referencing the dll. I am using installshield LE with VS2012 to create an installer for the windows service. Installshield is getting an old version of the referenced dll from my Asp.net cache, Not the bin\release folder. I can confirm this by the date time stamp of the deployed dll.
What should I do? In the short term I am going to try directly referencing the files instead of using the project output.
What should I do? In the short term I am going to try directly referencing the files instead of using the project output.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 02, 2013
05:48 AM
Hello,
Have you tried adding the libraries directly to your InstallShield project instead of adding from project output group reference?
Thanks,
Chiranjeevi
Have you tried adding the libraries directly to your InstallShield project instead of adding from project output group reference?
Thanks,
Chiranjeevi
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 22, 2013
12:12 PM
I have found that I have had the same problem. It seems that when it detects the dependencies, it will sometimes take them from ASP.NET Temporary folder and not the compiled folder.
I have run into this problem a couple of times now and adding the DLL directly to the install will work, but is not the ideal solution. I posted a thread right before I read this and deleting the Temp Folder solves the problem, at least temporary.
It seems to manifest itself after you change the references in a project to something different.
I have run into this problem a couple of times now and adding the DLL directly to the install will work, but is not the ideal solution. I posted a thread right before I read this and deleting the Temp Folder solves the problem, at least temporary.
It seems to manifest itself after you change the references in a project to something different.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 03, 2013
02:07 PM
This is definitely a problem, but there seems to be no feedback or information from Flexera? It doesn't seem fair to have to pay $250 for an incident to help fix a bug!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 04, 2013
04:29 AM
Hello,
We brought this issue to the notice of our engineering team and they are currently looking into this issue.
As a workaround you may try adding the known files and their dependencies manually instead of adding from project output group to properly scan the dependencies.
Any inconvenience regretted.
Thanks,
Chiranjeevi
We brought this issue to the notice of our engineering team and they are currently looking into this issue.
As a workaround you may try adding the known files and their dependencies manually instead of adding from project output group to properly scan the dependencies.
Any inconvenience regretted.
Thanks,
Chiranjeevi