Problems with Fseek3 in X# 2.7

[ic2]

Hello Chris, Robert,

Hi Dick,

Oh, come on now, how much time does it take to copy one dll file in 3 folders in the disk?

The problem with creating complete installers just for such small fixes is that a new installer needs A LOT of testing,

I think I clearly explained why this is too much work. The readme.txt says:

To install:
- Register XSharp.Core.DLL in the GAC


And not: copy it to
C:WindowsMicrosoft.NETassemblyGAC_MSILXSharp.Corev4.0_2.6.0.0__ed555a0467764586

If that was in the readme.txt I wouldn't even have posted this.

Sorry to hear that your installer procedure is so complicated. I would say that every installer just collects the files and possible settings so 1 changed DLL creates exactly the same setup as before with only that DLL changed.

And about the GAC, fortunately I have never needed to hack the GAC for anything or ask users of my software to do the same. I once had to clear it I remember because Windows was using an old version of a DLL if I remember correctly, because of the GAC. Which proves that the GAC is one of the many failures Microsoft invented.

Dick

[Chris]

Hi Dick,

"Registering" it to the GAC is the "official" way to do it, as MS instructs. Unofficially, for us code anarchists, the "at your own risk" method of simply copying the file works just fine.

It does not matter if the installation procedure is complicated or not, the issue is that we do not want to spend ages testing stuff every time we release a very small fix, so releasing a single dll file when needed is I think the most efficient approach for all.

[robert]

Dick,

Sorry to hear that your installer procedure is so complicated. I would say that every installer just collects the files and possible settings so 1 changed DLL creates exactly the same setup as before with only that DLL changed.
/quote]

The procedure is not complicated. Our product is. The installer deploys over 900 files. They all have to be of the right version.
Since we are working with a team on several components at the same time, we have to make sure that things work correctly.
When the new macro compiler DLL was created we had also touched many other parts of the program.
To make sure that these new changes do not get included in the installer (since some of them may introduce new problems) we have to:
- Check in all source code
- Check out the source code from the last setup
- Roll forward the source code for the changed component (the macro compiler in this situation)
- Build everything
- Run our unit tests, to be sure that the first 2 steps were executed correctly
- Update the documentation (include the description for the changes in the changed component),: help & what's new.
- Build the new setup
- Test the new setup on different configurations of machines.
- Upload the new setup to the website

This is simply a lot (several hours) of work, but we have to do it in a structured manner. It is very easy to "think" that nothing was changed in other components since the last setup was made but past experience has learned us that it is very easy to make mistakes.

Robert