By Edhy Rijo - 5/18/2009
I am using the SF Infragistics Wrapper and I am getting an error when try to install this assembly into the GAC using InstallAware.
When I build my installation package I don't get any error and the other SF assemblies are installed just fine. Of course I had to compiled the "MicroFour StrataFrame Infragistics Wrapper.dll" in order to use my version of Infragistics library.
In my computer works just fine, only when I build the installation setup and test under Vista and XP (32BITS).
I will appreciate if somebody can give me a hint on this one.
|
By Edhy Rijo - 5/18/2009
See attached image for the list of SF assemblies selected.
|
By Trent L. Taylor - 5/18/2009
This looks more like an InstallAware problem. I have fought this before where the temp file gets removed due to a virus software, invalid permissions, etc. These are always fun things to fight. But within InstallAware, every time I have fought this, it was becuase the physical file on disk really isn't there and had been cleaned up or removed.
I have gotten around this several ways depending on how it was manifested. Generally the first thing I will do is open up the %temp% folder and remove any mia*.* folders and files. Then start over. This fixes about 50% of the problems. 25% of the time turning off a real-time anti-virus solution fixes the problem. 10% of the time if it is an update, the original {GUID} folder they create in the Application Data folder has to be manually deleted due to some type of corruption. Another 10% of the time it is permission issues. Generally when it is permissions there is an IT person who really locks down the temp folders, etc. and makes life fun. 5% of the time it is a legitimate issue.
I am not sure which category you are falling into...but this is a relatively common message.
|
By Edhy Rijo - 5/18/2009
Thanks Trent,
Will try all that. What is extrange is that only happen with this file which I had to re-build, other SF assemblies install just fine. I even try to manually drop this file into the GAC and get an error, even though I am logged as administrator with all the rights using VPC.
|
By Trent L. Taylor - 5/18/2009
If you just place that DLL in the same location as your EXE does the application run? We have actually moved away from GAC additions and it has made things far easier. In the future we will do the same with SF so that it makes it easier to run multiple versions of SF at the same time easier.
|
By Edhy Rijo - 5/18/2009
Trent L. Taylor (05/18/2009)
If you just place that DLL in the same location as your EXE does the application run? We have actually moved away from GAC additions and it has made things far easier. In the future we will do the same with SF so that it makes it easier to run multiple versions of SF at the same time easier.
Yeah, moving all SF assemblies to the EXE folder did the trick. Obviously this should be an InstallAware problem since for whatever reason the file was not included in the OFFLINE Web Media Group.
I noticed that by having all assemblies in the same folder as the EXE there is not need to register anything which in a way makes it simple, even though I kind it like the assemblies files being in another folder.
Thanks again for your input, it really helped and now I can demo beta 2 of the application to the customer tomorrow. 
|
By Trent L. Taylor - 5/19/2009
You can actually put the assemblies in a different folder without the need for the GAC. In your application you can handle the AssemblyResolve event on the AppDomain and pull the assembly from any location. Here is a quick sample, it may need some work, but it should give you a general idea:
Add this to the InitApplication or someplace far up in the AppMain
AddHandler AppDomain.CurrentDomain.AssemblyResolve, AddressOf ResolveAssemblyLocation
Here is the general idea for the ResolveAssemblyLocation method:
Private Shared Function ResolveAssemblyLocation(ByVal sender As Object, ByVal e As System.ResolveEventArgs) As System.Reflection.Assembly
'-- Establish Locals
Dim r As System.Reflection.Assembly
Dim assemblyPath As String = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location) & "\Assemblies\"
r = System.Reflection.Assembly.LoadFile(assemblyPath & e.Name)
Return r
End Function
Hope this helps. 
|
By Edhy Rijo - 5/19/2009
Thanks, definitely worth trying, I like to have my Application's folder organized, and frankly I don't like to see a whole bunch of files in a single folder.
|
By Greg McGuffey - 5/19/2009
Can something like this be done to override an assembly being installed in the GAC and also in local? I.e. if the SF assemblies are in the GAC (like on a dev machine), but I need to run an older version of the app, with older SF assemblies and have those assemblies in the exe folder, can I use this method to use the local ones instead of the one's in the GAC?
|
By Keith Chisarik - 5/19/2009
Great conversation, I would also love to do this, I think the GAC was a decent idea in concept, but a failure in practical implementation.
|
By Trent L. Taylor - 5/20/2009
Can something like this be done to override an assembly being installed in the GAC and also in local?
Sadly, no. If an assembly is in the GAC, it will get pulled from the GAC. If the version and signature are the same, then it is practically impossible (notice I did say practically  ) to load that assembly into the AppDomain from anywhere except the GAC. This is why we are moving away from using the GAC all of the time. When dealing with an application in the field, it is far easier to be able to just copy a new file into the local client folder versus begging the old one out of the GAC and coaxing the new one in. It has made support far easier for our services department when dealing with our medical application. It will also make it far easier for us to support multiple SF versions within the VS IDE in the future as well.
|
By Greg McGuffey - 5/20/2009
OK. Well, just a thought. Are you moving away from this for SF or just in your medical app?
|
By Trent L. Taylor - 5/20/2009
All SF assemblies will still support the GAC no matter what we do. But we will probably, in the long run, move away on both. We have already done this on our medical app.
|
By Greg McGuffey - 5/21/2009
That's good news. I've had issues were I've upgraded SF for development, then couldn't run an installed production app on the same computer because of this (I just end having to run the production app on another computer).
|
By Edhy Rijo - 5/21/2009
I also support the idea of having the assemblies located per application.
Also Trent, where are we going to see a major SF update and what are the features that will make it in that update?
I would like to see SF support for .NET 3.5 since 3.5 have support for the compiled .EXE to be run from a network share without the need to tweak the security policy in each workstation, and also it is suppose to be faster at loading the assemblies. I know that now I can compile my project using .NET 3.5 but then I guess the SF assemblies would have to be in the GAC.
|
By Trent L. Taylor - 5/26/2009
I would like to see SF support for .NET 3.5 since 3.5 have support for the compiled .EXE to be run from a network share without the need to tweak the security policy in each workstation, and also it is suppose to be faster at loading the assemblies. I know that now I can compile my project using .NET 3.5 but then I guess the SF assemblies would have to be in the GAC.
Edhy, you can do this now and it doesn't require an update. If you handle the AppDomain.CurrentDomain.AssemblyResolve event then you do not have to put your assemblies in the GAC and can put them in any folder you like, regardless of the .NET version.
Also Trent, where are we going to see a major SF update and what are the features that will make it in that update?
This is a long conversation. There are going to be a lot of new features. We have just downloaded VS2010 and starting looking at .NET 4.0 in more detail. So most likely we will develop towards .NET 4.0 which will take advantage of everything that .NET 3.5 has to offer and more.
But one thing that we are going to take very seriously is backward compatibility and having a migration process forward. .NET 3.5 is developed on .NET 2.0. But if we were to pull the plug totally on .NET 2.0 it would hurt a lot of people. So we will be adding new functionality while still making sure that all existing applications have a migration path forward. This is another major benefit of us having the medical application. It gives us a chance to go ahead of everyone on this front and work through the process.
|
By Edhy Rijo - 5/26/2009
Trent L. Taylor (05/26/2009)
I would like to see SF support for .NET 3.5 since 3.5 have support for the compiled .EXE to be run from a network share without the need to tweak the security policy in each workstation, and also it is suppose to be faster at loading the assemblies. I know that now I can compile my project using .NET 3.5 but then I guess the SF assemblies would have to be in the GAC.
Edhy, you can do this now and it doesn't require an update. If you handle the AppDomain.CurrentDomain.AssemblyResolve event then you do not have to put your assemblies in the GAC and can put them in any folder you like, regardless of the .NET version.
This is a very important need for me since 99% of my current VFP customers have their application running from a shared folder. So you are saying that if I compiled my SF project with .NET 3.5, the SF assemblies can be installed on a shared folder with my .EXE file without the need for me to tweak the security policies in each workstation?
But one thing that we are going to take very seriously is backward compatibility and having a migration process forward. .NET 3.5 is developed on .NET 2.0. But if we were to pull the plug totally on .NET 2.0 it would hurt a lot of people. So we will be adding new functionality while still making sure that all existing applications have a migration path forward. This is another major benefit of us having the medical application. It gives us a chance to go ahead of everyone on this front and work through the process.
I agree with you on being careful not to break our current applications, and do appreciate that 100%, but at some point we also need to move forward and that will required us to make changes to our base code. Look what happen to VFP by trying to keep backward compatibility with FOX 1.x. I know that as a company it will not depend on one member of the team to move forward, but if MicroFour would share with their community their future plans with SF (specific features), then you will have more feedback from us on what we would like to see in SF and our applications.
|
By Trent L. Taylor - 5/26/2009
This is a very important need for me since 99% of my current VFP customers have their application running from a shared folder. So you are saying that if I compiled my SF project with .NET 3.5, the SF assemblies can be installed on a shared folder with my .EXE file without the need for me to tweak the security policies in each workstation?
Correct. You can do this right now. We have a number of developers using .NET 3.5, WPF, etc.
I agree with you on being careful not to break our current applications, and do appreciate that 100%, but at some point we also need to move forward and that will required us to make changes to our base code. Look what happen to VFP by trying to keep backward compatibility with FOX 1.x. I know that as a company it will not depend on one member of the team to move forward, but if MicroFour would share with their community their future plans with SF (specific features), then you will have more feedback from us on what we would like to see in SF and our applications.
This is in no way what I was trying to suggest. That is why I was referring also to a "migration" as well. Migrations generally mean that there is a process to move forward. We have never been a company to stifle ourselves in this regard. We will move forward providing a clear path to move applications forward using new technologies that are available and coming down the pike.
|
By Edhy Rijo - 5/26/2009
Trent L. Taylor (05/26/2009)
[codesnippet]This is in no way what I was trying to suggest. That is why I was referring also to a "migration" as well. Migrations generally mean that there is a process to move forward. We have never been a company to stifle ourselves in this regard. We will move forward providing a clear path to move applications forward using new technologies that are available and coming down the pike.
Thanks, glad to hear that. As for 3.5 I will do some test in the following weeks, since now I have to move forward with my current project, but if I can make my SF/.NET applications run from a shared folder it will make my life a bit easier since I am more comfortable with having one single application to update instead of multiple workstations, even though there are a lot of pro/cons to both type of installations and their maintenance and I may be searching for an "old dog" here .
I am very concern on being able to lower the internal maintenance cost of my applications, and kind a like to build applications that will be maintenance free for the user in a sense of updating their current applications. For my VFP applications I had a very stable process using Stonefields tools and others and I am trying to get to that point with SF and DDT as well as other 3rd party tools.
On a second though, forget about everything we where talking here and bring us the SF Licensing Manager Tools instead sorry, just thinking out loud 
|
By Trent L. Taylor - 5/26/2009
LOL....that is not the first time that has come up. We will consider it once we have the new SF version written and our the door.
FWIW, you will lose performance running an application from a network share....if you have the option of moving this to a local machine at some point you will be better served. There are other security risks outside of the .NET security that can come up...and if you run into a "by the book" IT person, you can have a fight on your hands. Just a few thoughts.
|