Solution Build question / issue....

[JCauble]

1. We have a web project that has a support dll that uses the following
command: HttpContext.Current.Application["key...."].ToString();

2. In our environment we must use a build process that runs from the
command line to get things into production, not the IDE.

The problem. When we compile the project in the IDE everything works great,
the application works the support DLL gets the current context stuff and
everything is just fine. However when we run the project through the CSC
compiler everything compiles and looks good but when we run the application
it blows up on the line of code for the HTTPContext stuff. Now if I change
it to ConfigurationSettings and try to pull from web.config it works fine.

So the problem is what is the IDE doing differently. We know everything is
getting compiled correctly as it works upto that one point in the support
dll.

Here are the base options we use on the command line since we use a RSP file.

/target:library
/optimize+
/warn:4

/r:System.dll
/r:System.Drawing.dll
/r:System.Data.dll
/r:System.Web.dll
/r:System.XML.dll
/r:OurDLLGoesHere.dll

<fileList for compilation>

There is not much to do here but it looks like there is something that the
IDE is injecting into the DLL as it is also 4 K smaller when we compile on
the command line.

Anybody ever run into this before? We do need to keep it as the HTTPContext
if possible so we need to figure out why it won't link in for some unknown
reason....

Thanks.

[Scott Allen]

When you say it blows up, do you mean you get a null reference
exception?

Are you sure Application["key"] doesn't return a null value?

Do you have any code inside of conditional compilation directives (#if
/ #endif) where the symbol might be defined in the IDE but not in the
command line build?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 12 Aug 2005 09:22:01 -0700, "JCauble"
<JC*****@discussions.microsoft.com> wrote:

1. We have a web project that has a support dll that uses the following
command: HttpContext.Current.Application["key...."].ToString();

2. In our environment we must use a build process that runs from the
command line to get things into production, not the IDE.

The problem. When we compile the project in the IDE everything works great,
the application works the support DLL gets the current context stuff and
everything is just fine. However when we run the project through the CSC
compiler everything compiles and looks good but when we run the application
it blows up on the line of code for the HTTPContext stuff. Now if I change
it to ConfigurationSettings and try to pull from web.config it works fine.

So the problem is what is the IDE doing differently. We know everything is
getting compiled correctly as it works upto that one point in the support
dll.

Here are the base options we use on the command line since we use a RSP file.

/target:library
/optimize+
/warn:4

/r:System.dll
/r:System.Drawing.dll
/r:System.Data.dll
/r:System.Web.dll
/r:System.XML.dll
/r:OurDLLGoesHere.dll

<fileList for compilation>

There is not much to do here but it looks like there is something that the
IDE is injecting into the DLL as it is also 4 K smaller when we compile on
the command line.

Anybody ever run into this before? We do need to keep it as the HTTPContext
if possible so we need to figure out why it won't link in for some unknown
reason....

Thanks.

[JCauble]

Also, Did a little more digging and found something interesting.... Not sure
what to do though.

I added a clientscript (from codebehind) to output the
httpContext.Current.Applicatino["key"]'s Value and when I run from the
compile in the IDE it spits out the LDAP key. When I run the same code as
compiled through the command line I get an Object Reference Error....

Any reason why the web project would not compile correctly? The output type
is Library and it has the same references defined as what is listed in the
project file. We even tried setting the references to the csc.rsp file
values and no luck either. It's almost like it's missing an assyembly
reference or something around that object but for the life of us we don't
know what it could be since the CSC compiler compiles just fine....

Any thoughts?????

"Scott Allen" wrote:

When you say it blows up, do you mean you get a null reference
exception?

Are you sure Application["key"] doesn't return a null value?

Do you have any code inside of conditional compilation directives (#if
/ #endif) where the symbol might be defined in the IDE but not in the
command line build?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 12 Aug 2005 09:22:01 -0700, "JCauble"
<JC*****@discussions.microsoft.com> wrote:

1. We have a web project that has a support dll that uses the following
command: HttpContext.Current.Application["key...."].ToString();

2. In our environment we must use a build process that runs from the
command line to get things into production, not the IDE.

The problem. When we compile the project in the IDE everything works great,
the application works the support DLL gets the current context stuff and
everything is just fine. However when we run the project through the CSC
compiler everything compiles and looks good but when we run the application
it blows up on the line of code for the HTTPContext stuff. Now if I change
it to ConfigurationSettings and try to pull from web.config it works fine.

So the problem is what is the IDE doing differently. We know everything is
getting compiled correctly as it works upto that one point in the support
dll.

Here are the base options we use on the command line since we use a RSP file.

/target:library
/optimize+
/warn:4

/r:System.dll
/r:System.Drawing.dll
/r:System.Data.dll
/r:System.Web.dll
/r:System.XML.dll
/r:OurDLLGoesHere.dll

<fileList for compilation>

There is not much to do here but it looks like there is something that the
IDE is injecting into the DLL as it is also 4 K smaller when we compile on
the command line.

Anybody ever run into this before? We do need to keep it as the HTTPContext
if possible so we need to figure out why it won't link in for some unknown
reason....

Thanks.

[JCauble]

Basically the problem is that it never gets the items... When we compile the
application 2 projects (1 web project, 1 DLL project) whether they are in the
same solution or not from the IDE everything works fine. When we compile
the same application from the command line it don't work and the dll file for
the web app is smaller.

Both compiles are in Release mode, IDE and command line. There is obviously
something we are either missing or that the IDE is doing in order to make
this work.

What we did is in the Support DLL there are three calls to the HTTPContext
object that set variables in the class for LDAP lookups. When the error
fires it is because these values are empty and not set. However when we
compile from the IDE the variables do get set.

There is no rhyme or reason to this so now we have to figure it out....

It makes me wonder if the IDE is setting some sort of hook or something for
the support DLL in the Web Project DLL.....

And there are no compile directives at all in the appliation.

"Scott Allen" wrote:

When you say it blows up, do you mean you get a null reference
exception?

Are you sure Application["key"] doesn't return a null value?

Do you have any code inside of conditional compilation directives (#if
/ #endif) where the symbol might be defined in the IDE but not in the
command line build?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 12 Aug 2005 09:22:01 -0700, "JCauble"
<JC*****@discussions.microsoft.com> wrote:

1. We have a web project that has a support dll that uses the following
command: HttpContext.Current.Application["key...."].ToString();

2. In our environment we must use a build process that runs from the
command line to get things into production, not the IDE.

The problem. When we compile the project in the IDE everything works great,
the application works the support DLL gets the current context stuff and
everything is just fine. However when we run the project through the CSC
compiler everything compiles and looks good but when we run the application
it blows up on the line of code for the HTTPContext stuff. Now if I change
it to ConfigurationSettings and try to pull from web.config it works fine.

So the problem is what is the IDE doing differently. We know everything is
getting compiled correctly as it works upto that one point in the support
dll.

Here are the base options we use on the command line since we use a RSP file.

/target:library
/optimize+
/warn:4

/r:System.dll
/r:System.Drawing.dll
/r:System.Data.dll
/r:System.Web.dll
/r:System.XML.dll
/r:OurDLLGoesHere.dll

<fileList for compilation>

There is not much to do here but it looks like there is something that the
IDE is injecting into the DLL as it is also 4 K smaller when we compile on
the command line.

Anybody ever run into this before? We do need to keep it as the HTTPContext
if possible so we need to figure out why it won't link in for some unknown
reason....

Thanks.

[JCauble]

We found the problem. THere was an embedded resource that was being grabbed
before the stuff was set and that was failing.... Added the Embedded
resource command to the RSP file for the command line and now it works like a
champ.

"Scott Allen" wrote:

When you say it blows up, do you mean you get a null reference
exception?

Are you sure Application["key"] doesn't return a null value?

Do you have any code inside of conditional compilation directives (#if
/ #endif) where the symbol might be defined in the IDE but not in the
command line build?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 12 Aug 2005 09:22:01 -0700, "JCauble"
<JC*****@discussions.microsoft.com> wrote:

1. We have a web project that has a support dll that uses the following
command: HttpContext.Current.Application["key...."].ToString();

2. In our environment we must use a build process that runs from the
command line to get things into production, not the IDE.

The problem. When we compile the project in the IDE everything works great,
the application works the support DLL gets the current context stuff and
everything is just fine. However when we run the project through the CSC
compiler everything compiles and looks good but when we run the application
it blows up on the line of code for the HTTPContext stuff. Now if I change
it to ConfigurationSettings and try to pull from web.config it works fine.

So the problem is what is the IDE doing differently. We know everything is
getting compiled correctly as it works upto that one point in the support
dll.

Here are the base options we use on the command line since we use a RSP file.

/target:library
/optimize+
/warn:4

/r:System.dll
/r:System.Drawing.dll
/r:System.Data.dll
/r:System.Web.dll
/r:System.XML.dll
/r:OurDLLGoesHere.dll

<fileList for compilation>

There is not much to do here but it looks like there is something that the
IDE is injecting into the DLL as it is also 4 K smaller when we compile on
the command line.

Anybody ever run into this before? We do need to keep it as the HTTPContext
if possible so we need to figure out why it won't link in for some unknown
reason....

Thanks.

[Scott Allen]

Good find!

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Fri, 12 Aug 2005 11:36:11 -0700, "JCauble"
<JC*****@discussions.microsoft.com> wrote:

We found the problem. THere was an embedded resource that was being grabbed
before the stuff was set and that was failing.... Added the Embedded
resource command to the RSP file for the command line and now it works like a
champ.