E
EO
I am trying to use the MSFT data access application block on 3 machines.
Machine 1:
Sandbox environment; I installed the application block with the msi. The
Sqlhelper class compiles & runs great! (Also the SqlhelperParameterCache
class; I'll refer to them collectively as the SqlHelper class.) I'm using
unmodified application block code in all cases.
Machine 2:
Development environment, different project
I don't know if the msi does anything I could not replicate on the machine 3
to which I don't have console access and will deploy this project, so I have
taken the cautious approach. I copied the SqlHelper.vb to the project on
machine 2 & hit build. I got a facefull of errors:
a) Machine 2 did not have a project reference to system.xml, which machine 1
did. They now have identical references with exception that machine 2 also
has a project reference to msocorlib and machine1 does not.
b) I added imports statements to the machine 2 SqlHelper class file: Adding
Imports to System, System.Data, & System.Collections, all references
resolved except item c.
c) I still have a "name 'iif' not declared" error for the one iif statement
in the code.
Machine 3:
Production environment on a hosted server to which I have only ftp access.
So...
a) what namespace do I have to import to get my iif back?
b) Please help me understand why the same code compiles fine on machine 1
but requres extra imports statments on machine 2 despite identical project
references?
c) Is the mscorlib reference necessary?
d) extra credit
I also added another class on machine 2 from machine 1
(no dependencies with SqlHelper). Machine 1 accesses
configurationsettings.appsettings without importing system.configuration,
but machine 2 requires me to import system.configuration.
Alert item: Machine 2 runs ZoneAlarmPro, which does not play well with
vs.net. I disable Zonealarm during development, but it may have been on when
vs.net was installed or the project created. Therefore, "FDisk" may be a
legitemate solution. :-(. (Oh please, oh please, noooooo)
Article links or direct answers equally appreciated.
Machine 1:
Sandbox environment; I installed the application block with the msi. The
Sqlhelper class compiles & runs great! (Also the SqlhelperParameterCache
class; I'll refer to them collectively as the SqlHelper class.) I'm using
unmodified application block code in all cases.
Machine 2:
Development environment, different project
I don't know if the msi does anything I could not replicate on the machine 3
to which I don't have console access and will deploy this project, so I have
taken the cautious approach. I copied the SqlHelper.vb to the project on
machine 2 & hit build. I got a facefull of errors:
a) Machine 2 did not have a project reference to system.xml, which machine 1
did. They now have identical references with exception that machine 2 also
has a project reference to msocorlib and machine1 does not.
b) I added imports statements to the machine 2 SqlHelper class file: Adding
Imports to System, System.Data, & System.Collections, all references
resolved except item c.
c) I still have a "name 'iif' not declared" error for the one iif statement
in the code.
Machine 3:
Production environment on a hosted server to which I have only ftp access.
So...
a) what namespace do I have to import to get my iif back?
b) Please help me understand why the same code compiles fine on machine 1
but requres extra imports statments on machine 2 despite identical project
references?
c) Is the mscorlib reference necessary?
d) extra credit
I also added another class on machine 2 from machine 1(no dependencies with SqlHelper). Machine 1 accesses
configurationsettings.appsettings without importing system.configuration,
but machine 2 requires me to import system.configuration.
Alert item: Machine 2 runs ZoneAlarmPro, which does not play well with
vs.net. I disable Zonealarm during development, but it may have been on when
vs.net was installed or the project created. Therefore, "FDisk" may be a
legitemate solution. :-(. (Oh please, oh please, noooooo)
Article links or direct answers equally appreciated.