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.

OK. Well, just a thought. Are you moving away from this for SF or just in your medical app?

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.

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).

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.

Edhy Rijo

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 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.

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?









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.

Edhy Rijo

Correct. You can do this right now. We have a number of developers using .NET 3.5, WPF, etc.







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

Edhy Rijo

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.