ASP.NET BuildProvider's and issue RSRP-25954

A long time ago (back in the ReSharper 2.0 days), I filed a bug about the lack of support for custom ASP.NET BuildProvider's within ReSharper. The bug is RSRP-25954. I was quite elated a couple weeks ago when I got an email from the tracker saying the bug had been fixed on version 4. Today I finally got around to trying the latest EAP build (777), but unfortunately, it seems it has not been fixed. I have created a very simple sample solution (attached) that repros the fact tha ReSharper is still not recognizing the code generated by the custom BuildProvider. You will note that in the code behind of Default.aspx, the line of code is highlighted in red, when in fact it compiles fine.

~Andy



Attachment(s):
BrokenBuildProvider.zip
10 comments
Comment actions Permalink

Andy,

The scenario isn't supported yet. Hope, will fix it the nearest future. If
you use build provider from referenced dll everything should work fine.

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Fixed

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hello Sergey,

Thank you for fixing that issue. However, I think I have discovered another one. I have attached a sample solution that illustrates. Basically, if I have one of my config sections using the configSource attribute that points to an external file that lives in a subdirectory of the website, it seems the build provider support code within ReSharper throws an exception, and thus does not work.

In my sample solution, my appSettings section in my web.config is pointing to an external file like this:

]]>

The code generated by the build provider shows up in red, and when I view the ReSharper log, I see an exception message that is attached.

It seems that the web.config is being copied to a temp directory, and then being opened. However, there is other stuff (in this case, my child config file) this is not being copied, and thus the exception is being thrown.

I am not sure on the reasoning behind opening the web.config from a temp directory, as opposed to opening it from its original location, but that approach seems problematic to me. On of the methods available in the build provider, is OpenReader(String virtualPath), where it allows you to open up and read any arbitrary file within the web site. It seems that means you need to either copy the entire web project tree to make it work (probably a really bad idea for large web projects), or open up the config from the original location.

~Andy

Fixed



Attachment(s):
BuildProviderException.txt
BuildProviderBroken.zip
0
Comment actions Permalink

Andy,

Fixed.
--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Wow! Thanks so much for the quick response (and fix) Sergey. I will take
a look at it as soon as the next nightly build is posted.

~Andy

Andy,

Fixed.



0
Comment actions Permalink

Hello Sergey,

I tried to verify your fix in the latest build (481) but it still seems to
be broken. I used the same sample solution that I sent before. I don't
see the exception in the log like before, but the code is still highlighted
in red...

~Andy

Andy,

Fixed.



0
Comment actions Permalink

Andy,

I tried to verify your fix in the latest build (481) but it still seems to
be broken. I used the same sample solution that I sent before. I don't
see the exception in the log like before, but the code is still
highlighted in red...

What build are you using? I've just checked against 783 - everything is ok


--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hello Sergey,

I was using 781. I have not tried 783 as it is not available yet as far
as I can tell. I will try it as soon as it appears on the nightly build
page and let you know the results.

~Andy

Andy,

>> I tried to verify your fix in the latest build (481) but it still
>> seems to be broken. I used the same sample solution that I sent
>> before. I don't see the exception in the log like before, but the
>> code is still highlighted in red...
>>

What build are you using? I've just checked against 783 - everything
is ok



0
Comment actions Permalink

Hello Sergey,

I was able to verify that the build provider in the sample solution works
for me now (in build 783). However, I am still unable to get it to work
in my real (much larger) website project. Looking at the ReSharper log,
it seems that the BuildProviderSupportManager is continually postponing its
build, and never actually performs it. I am seeing about 100 entries in
a row in the log file like this:

12:25:36 PM.343: Thread:1: RebuildWebsite postponed
12:25:36 PM.343: Thread:1: RebuildWebsite postponed
12:25:36 PM.343: Thread:1: RebuildWebsite postponed

In the log of the sample solution, the RebuildWebsite is postponed a couple
times, but then it is performed. The log for that looks like this:

1:25:52 PM.824: Thread:17: BbuildWebsite started
...other stuff...
1:25:54 PM.356: Thread:17: BbuildWebsite finished


In my larger website, I never see a started or finished entry. Note that
I am using the exact same build providers in both cases, so it seems that
something else is going on that is preventing it from working. Do you have
any ideas?

~Andy

PS I did notice that there are many instances of the following exception
in the logs. Could this be related?

12:25:26 PM.625: Thread:1: EXCEPTION: Value does not fall within the expected
range.
System.ArgumentException: Value does not fall within the expected range.
at EnvDTE.Properties.Item(Object index)
at JetBrains.VSIntegration.ProjectModel.VSProjectInfo.GetNoStdLibProperty(Properties
properties) in c:\Agent\work\be901b19a2aeff47\Platform\src\VSIntegration\src\ProjectModel\VSProjectInfo.cs:line
384



Hello Sergey,

I was using 781. I have not tried 783 as it is not available yet as
far as I can tell. I will try it as soon as it appears on the nightly
build page and let you know the results.

~Andy

>> Andy,
>>
>>> I tried to verify your fix in the latest build (481) but it still
>>> seems to be broken. I used the same sample solution that I sent
>>> before. I don't see the exception in the log like before, but the
>>> code is still highlighted in red...
>>>
>> What build are you using? I've just checked against 783 - everything
>> is ok
>>




0
Comment actions Permalink

Andy,

could you send me the log file for investigation?
My direct e-mail is qx jetbrains com

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

Please sign in to leave a comment.