Is there anyone here who can help???

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=5241

I'm still with you ;-) and still looking / trying.

As a possibility look at http://forums.asp.net/907365/ShowPost.aspx

Alle

I'm glad someone is still with me   Unfortunaitly the last post didn't help as the files needed to be present but part of the solution are user controls...  Besides I understand there is no longer a DLL created when you build the project, as it is compiled on the fly by the dotNet 2.0 framework.

This is what I believe breaks the functionality   Since it's compiled on the fly, they didn't build in a way to exclude  folders/files from being built and compiled on the fly.

Regards,

Look at this thread http://forums.asp.net/908569/ShowPost.aspx

Especially the last two post from Omar and Simon.

It's not very nice, since it requires command line compiler options, but it should work.

Alle

You exclude a file by not putting it in your web directory. Why do you need a file in the directory if it's not supposed to be included in some way?

[Edit: Oh, and I'm speaking in the context of ASP.NET here. I didn't know if your question was about more general VS.NET development.]

-Brock

 

An ASP.NET Component (http://Telerik.Com) requires ascx files to be in the directory structure, but NOT part of the solution as they have thier own DLL file bound to them.  Within this directory is ONE (1) aspx file that DOES need to be apart of the solution and thus compiled as part of the solution.

Under 1.1, I could exclude the folder, and include the 1 file that was needed to be included.  I compiled and ran sucessfully.

Under 2.0 (beta 2) there is no way to exclude these files, and thus the framework tries to compile them as part of the solution which breaks the functionality.  (Actually, they won't even compile because thier code-behind is already in a DLL sitting in the BIN folder)

C4702 wrote:

An ASP.NET Component (http://Telerik.Com) requires ascx files to be in the directory structure, but NOT part of the solution as they have thier own DLL file bound to them.  Within this directory is ONE (1) aspx file that DOES need to be apart of the solution and thus compiled as part of the solution.

Just so we're clear, they send you a source file to compile as part of your assembly? Compiling in VS.NET is simply compiling the codebehind files. This is why I say in v2.0 if you don't want an ASPX or ASCX to be part of your application, then it shouldn't be there in the first place.

I don't know enough about this product to offer an opinion about how they're doing things. But, it does sound like a vendor issue. This is going to be a problem for every one of their customers, so they're going to have to come up with a solution. I'd contact their customer support and ask them when they plan to have a fix.

C4702 wrote:

Under 2.0 (beta 2) there is no way to exclude these files, and thus the framework tries to compile them as part of the solution which breaks the functionality.  (Actually, they won't even compile because thier code-behind is already in a DLL sitting in the BIN folder)

Again, this is primarily do to how the compilation model is different in v2.0 vs. v1.1. Since v2.0 has a different model, the semantics of having files in the application directory are different thus my comments.

-Brock

 

Just so we're clear, they send you a source file to compile as part of your assembly? Compiling in VS.NET is simply compiling the codebehind files. This is why I say in v2.0 if you don't want an ASPX or ASCX to be part of your application, then it shouldn't be there in the first place.

Well, only one of the files needs to be included into my solution and modified as I see fit, and compiled as part of my solution.  The rest of the files are NOT to be included, they have their own DLL sitting in the BIN folder, and have their content encrypted / encoded making them difficult to view / change etc...

I don't know enough about this product to offer an opinion about how they're doing things. But, it does sound like a vendor issue. This is going to be a problem for every one of their customers, so they're going to have to come up with a solution. I'd contact their customer support and ask them when they plan to have a fix.

Yes, I've informed them of my talks with Microsoft, and they are working on the fix as we speak.  Also, MS has not ruled out having this feature completely removed (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=84ab7f2f-bdcd-4e66-acaa-8c57dc016254)  All those who would like to have this feature brought back, please go and VOTE on this issue!  The problem from MS point of view is the project file.  I believe we have a suggested workaround.  Go VOTE so MS will take this issue seriously!

I guess my beef with this is that ASP.NET v2.0 is a different way of doing things. The App_Data folder is the location for storing additional files. Also, I suspect the reason for the files on the filesystem in the first place was really a workaround for something they weren't able to achieve. I don't see why they couldn't have just embedded the extra files as resources in the assembly, rather than having these extra files on the filesystem.

Anyway, good luck with the petition. I voted ;)

-Brock

 

Is it just me or am I the only one that uses VSS and works on development team.  It's often the case that we will reference several projects for base functionality for a Website project.  All the dll's go in the Bin directory.  Now you are telling me that these files have to be checked in to source control over and over and over?  I don't have any need for any of these files to go into source control.  Part of the point of abstracting the functionality is that it is modular and exists somewhere else, I don’t want artifact cluttering up all my projects and source control.  I check out and build the base projects and I never include their dll's as part of my web project.  This should be so obvious.

 

Also, I now have to check files the size of 10MB like the application MDF into source control over and over?  Even when I'm the only one on the project with these settings?  This is the same issue, many times several different developers will be working on an individual DB for a project and individual settings.  This was actually a great opportunity to leave these individual settings OUT of source control!

 

The workaround works but is horrible for a team situation.  So what should I include a text document with the project to inform anyone who checks out the project what files and directories they have to hide so they don't get added to VSS and so that person can work on the project?

 

We've been working with projects for years on end and all of a sudden it's a good idea to just remove the whole concept?  And everyone who leveraged the power of having a project is now supposed to rethink it and use inefficient workarounds.  Why do people think that the only way to use a project is their way?  Please leave in existing project functionality it is very useful.

I voted, Please go Vote on this issue.

I have heard that the functionality is going back in for the final release.  What I have not heard is how that will be implemented.  If the same line of logic from MS is used I'm sure it will be less than a full fix.  Please go comment and vote on these issues.  There are 2 issues in the MSDN feadback center for these issues:

Just from a project perspective:
Bug Details: Exclude From Project / Include In Project not available in VS 2005 Web Applications
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=84ab7f2f-bdcd-4e66-acaa-8c57dc016254

From a VSS perspective:
Bug Details: VS Assumes All Files Under a Web Site Project Are To Be Checked Into Source Control
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=ddc06744-622d-474e-a9b0-d74a4617b589

A workaround of hidding your files from the project by using the hidden file/folder attribute is what is being suggested.  This is so irrelevent to a team situation and productivity!

The funny thing is I was just praising MS the other day on how they have included support for the XHTML spec, and how they have become SO flexible.  I was amazed at how MS was going a direction where the choices were left for the programmer.  And now this!?  A classic, "You don't need that functionality.  We know best."  Please, for the love of God, let us control what we want in a project and VSS.

MS could not even live up to the requirements of this new feature.  The've had to hard code in an exclusion for all .scc files.  I'm amazed at how they immediately find a need for this feature but assume all developers will not.

You can exclude the entire folder by putting the following web.config in it:

<configuration>

    <system.web>

        <compilation>

            <buildProviders>

                <clear/>

            </buildProviders>

        </compilation>

    </system.web>

</configuration>

OR

<configuration>

    <system.web>

        <httpHandlers>

            <clear/>

            <add verb="*" path="*" type="System.Web.HttpForbiddenHandler" />

        </httpHandlers >

    </system.web>

</configuration>

An exlclusion list reverses the original behavior of projects.  The original functionality of a project is to exclude files by default. Removing the project and creating an exclude list will reverse things so that files are all included by default. This will be the opposite of all other VS projects.

The who idea of building an exclusion list does not account for developers who leveraged the original design of having a project.  I don't want to clutter up my web.config file with project and development time only settings.  This has just shifted the project file that includes what is in the project to a web.config file that includes what is not in the project.  Why not just leave it the way it was?!  This even makes less sense when talking about deployment or working on a team.  Now I need a different deployement web.config without all the developers settings.  And on a team I don't always know or care what a developer may want to exclude from a project, but I always now what I want IN the project.

Again, please do not take away existing features that we rely on.