My team has multiple web application projects that have common components. In order to keep from having multiple instances, we have setup a common source that contains common classes and web project. In the web project, we would have MasterPage, pages, and user's controls that are shared as linked files from the main web application. each of the shared projects are included as part of the solution. The solution builds successfully, but when I open the page of the web app, I'm getting server stating that "The type 'Common.Controls.Master' is ambiguous: it could come from assembly 'C:....\bin\Common.Controls.DLL' or from assembly 'C:....\bin\AppWeb.DLL'. Please specify the assembly explicitly in the type name."
The actual Common.master resides in the Common.Controls project at the root. The link file to the master page is in the AppWeb project.
I've looked for solution and found this How to share Master Pages between my projects which is pretty much what I'm doing.
Another option I found was What is the best way to share MasterPages across projects. I haven't tried the methods in this one.
I was certain that using the linked file would work.
Thanks in advance in helping me resolve this error.
I faced a very similar issue recently with a different shared class.
Is it possible that the initial location of the MasterPage was under AppWeb project and then moved under Common.Controls project? In this case a build would not clean the previous dlls and would cause the error you are looking at. If this is the case, a simple manual deletion of all files under the bin folder of your projects and rebuild should solve the issue.
I hope this helps
Related
After importing this existing (and functional) site into Visual studio (tried 2017 and 2019 both) running .Net 4.0 I am getting a plethora of not found errors.
Codebehind pages are not able to see elements on the existing page
Classes are declared to be duplicated or ambiguous
Function names (both standard like Page_Load and custom) are reported as already defined.
I am sure that all these items are related. Here are the steps I followed:
Created new Web Application from Visual Studio 2017 template
Copied solution and csproject files into existing website folder
Added files into the project
Re-added references to site
Set custom class .CS files to Compile
Removed "unnecessary" using statements (which were already declared in web.config)
Create a new ProfileCommon stub referencing ProfileBase
Beyond all this I have tried renaming a number of these functions and classes (using the rename) to create a new reference point.
Not sure what else I can do on this beyond major changes or a complete rewrite (100+ pages of code so far) by creating the new class files then copy/paste.
What other options are open to me?
Ok, this is is a migration project. Only you can "determine" if you want to convert from a web site to a web site application, and the time and efforts for such a migration project.
Now, having stated the above? No question, that I prefer hands down a web site applications. Simple things like have VS compile and build the application, ability to add assemblies (and not have the mess of .dll's HAVING to be in the bin folder to resolve references - yuk!).
And then simple things like the ability to multiple projects in one project are things I come to enjoy, and expect over the years when developing software.
About the "only" thing going for a web site? Your deployment is oh so easy, since you can open a web page, or code behind, hit save, and you are done!
but, this means both source code (code behind) has to be deployed to the web site. As noted, I prefer a build and compile process in VS. This does mean that to make a "minor" change, then you have to do a full re-deploy of the whole site.
However, these benefits I like and enjoy? it not all a given that converting an existing web site to a web site application is worth the efforts. Only you can make this decision. On the other hand, you would not be doing this work unless you KNOW what you doing, and thus can determine if these efforts are worth the time.
Such a conversion and refactoring process is somewhat beyond a simple post on SO.
However some steps and tips are outlined here:
https://devblogs.microsoft.com/dotnet/converting-a-web-site-project-to-a-web-application-project/
I would consider starting over, and try the steps in above.
There is a "convert" option outlined in above, and this can save enormous amounts of time. It has been some time since I have attempted such a conversion, and I not tested the "convert" option in vs2022, and hopefully it still exists.
However, another possible option? Keep the site as web site.
I looked into all the articles and solutions (most of them coming from this site or the ASP.NET forums archives, and could not find a solution to my situation.
Basically, I have a project for which the master pages depend on another (compiled, .dll) project of Master pages. I installed it fine on my machine, and it runs fine, but when we did the same thing on a colleague's machine, it always gives us that 500 Server Error:
Could not load the assembly 'NAME_OF_ASSEMBLY'*. Make sure that it is
compiled before accessing the page.
An interesting point: it does not say "Could not load the assembly" with a name followed by and underscore and random letters, it just mentions the whole, proper name of the assembly.
Also weird point: The master pages (in the dependant project) all use some .dll files of compiled code. They have master pages that have no codebehind files, but do have the reference for the .dll included in that project. We tried copying all of those same files over, but to no avail.
We're simply at a point where we no longer know where to look or what to do. We reinstalled countless times, copied over my files, re-registered IIS, still nothing. Any pointers would be greatly appreciated.
Thank you all for your time!
I've just inherited a web application whose source has long been lost (originally written in 2010 and shelved). The application has a few .dll assemblies that related to the application itself e.g. "applicationCORE.dll", "applicationBI.dll", "applicationDATA.dll" and "application.dll"
I've seen this question and the suggested tool (Just Decompile) is brilliant and created a .sln and .csproj file for the first assembly that I decompiled. My question is how do I merge the various projects that would be created through decompiling with the compiled web application files (.aspx) also, how do I resolve the references in the .aspx files i.e. referencing the codebehind file that no longer exists e.g. "default.aspx" references "default.aspx.cs" while the decompiler creates a "default.cs" file. Is it safer to rename the .cs file or should I update the reference?
Finally, will each dll appear as a separate project within the solution?
I realise this may be perceived as a duplicate question however there doesn't appear to be a resource online that walks a developer through the process.
Following David's advice, I managed to get the application running from decompiled assemblies. Here's the process I followed to get it working
I had already decompiled the various assemblies into projects using a Reflector (on a trial).
I created a blank Web forms application in Visual Studio
I added the .aspx pages from the website to the project through visual studio
Then added the .cs files from the decompiled 'application.dll' project (since this is the website project within the solution. Some files had to be renamed to match the codebehind references in the `.aspx. files
Each additional project e.g. applicationCore.dll was then added to the solution
Each project's references needed to be updated and references to the newly added projects must be added to the startup project
Since the website was built so long ago, there were 1,000's of syntax errors. The easiest way to resolve them was to use Notepad++ and the Find and Replace. To be safe, I did this file-by-file by following the errors from Visual Studio rather than a batch find and replace
When trying to build I noticed errors where required assemblies were missing so I changed the build output directory of the sub-projects to the bin folder of the web project
I added the connection strings and settings from the original website's web.config. I did this line by line to make sure I didn't break anything and so that I could trace the result of each addition
Finally I had a successful build!
Additional Steps
There were also syntax errors which I assumed were due to the decompiling process. Some external references needed to be added and there were slight changes due to the age of the project e.g. asp:AjaxScriptControl changed to asp:ScriptControl (after adding the package using Nuget). I also had to install Crystal Reports for this application and will have to purchase a Telerik licence as there are UI components being used (although I'll see if I can use an open / native alternative as I work through the app).
I've logged in using credentials (I did have to set the correct start page) and tried a few basic CRUD operations. There are silly issues that have to be resolved e.g. the authentication doesn't work properly and there's no redirect if you access a protected page but these things are relatively minor compared to the issues I faced initially.
What I must say is each error was resolved using questions and answers from this site! This was all completed in just under 6 hours.
I have converted one huge Website Project into a Web Application Project as we want to have Compiled code in form of DLL for security purposes and followed below MSDN articles:
http://blogs.msdn.com/b/webdev/archive/2009/10/29/converting-a-web-site-project-to-a-web-application-project.aspx
http://msdn.microsoft.com/en-us/library/aa983476%28v=vs.100%29.aspx
The website is having 1000s of web pages/files. I have resolved all the issues of duplicate references, class name colisions and some compilation errors faced at on Build Solution stage. Due to the earlier website pattern, class names are in the following pattern:
for e.g. if UserMaster is in admin/Operations/Masters folder so the class name will be like: admin_Operations_Masters_UserMaster.
Now, Web Application is Building Successfully and when I try to run the application, it shows "Could Not Load Type 'ClassName'" so I found out that the issue of because Namespaces are absent due to earlier Website Pattern.
Found out in the MSDN:
By default, pages and classes that are built by using the Visual Studio Web site project model do not automatically include a code namespace. However, pages, controls, and classes that are built by using the Visual Studio Web application project model automatically include a code namespace. When converting the Web site project to a Web application project, you will have to add the namespaces to the code.
I have DEFAULT NAMESPACE in the project properties.
So I tried to add the namespaces to whole of the project via ReSharper -> Refactor -> Adjust Namespaces but its for .cs files only and not for .aspx.cs etc AND so its not working.
I thought I need to make a utility to add the namespaces automatically in pages as per their folder path structure but its a time consuming process.
So need a workaround to add the namespaces automatically in pages as per their folder path structure.
Secondly,
What I did for testing is, I have wrapped the default namespace in login page of the project where I faced 'could not load type issue', added in Inherits attribute also. Then did a Clean Solution then Rebuild Solution. But still getting the same issue.
I don't why DLL is not getting updated with the login page's class.
The strange thing is when I change the Codebehind to CodeFile (attribute of Page Directive) then the page is working very fine. Its due to source file is present at the time of running the project BUT i want to use Codebehind attribute as it will tell the compiler to look for the class in DLL not in Source file.
Finally, Summary is :
I have two major issues:
Could not load type 'className'
How to add the namespaces automatically in pages as per their folder path structure.
I have already searched here and came around different topics but nothing works for me. one have suggested to use "Surround With" feature of VS but I need to go one by one on each file which is NOT possible right now.
So Tried:
Set path of DLL to "bin" instead of "bin\debug"
Checked the Build Configuration and its of x86. also the DLL is present in bin
Checked all project properties and all are fine. Cleaned and rebuild solution hundreds of times. Cleaned Temporary ASP.NET files also.
Set Build Action to "Compile" for .cs class files
Cannot set Build action to Compile for aspx pages as they are static html and they should be set to "Content" which is default Build Action.
Resharper solution for adding namespaces but not working
Please help....
Any help will be greatly appreciated. Thanks.
Solved the Issue:
Earlier, I have tried to Set Build Action to "Compile" for .cs class files Only and for all the files sitewide to Compile from .csproj file but it was not working due to aspx page itself set to Compile which was not required.
Now, I have changed the Buid Action to Compile which was Content for .aspx.cs and .aspx.designer.cs files.
and it solved the issue.
Like for e.g.:
Solution 'TestWebApp1'
Project 'TestWebApp1' (ASP.NET Web Application)
Properties
References
App_Data
Scripts
Default.aspx (Build Action: Content)
Default.aspx.cs (Build Action: Compile)
SiteLayout.Master (Build Action: Content)
SiteLayout.Master.cs (Build Action: Compile)
Web.config
Source: None of my "code behind" code is being called
I just inherited a SharePoint project that I want to refactor and take all the common/reusable code and place it in a seperate project within the solution. The solution already has several projects, and almost all of the projects have dependencies between one or more other projects in the solution.
I want all of the depencies (SPMetal classes, static methods, utils, etc) to be put into one project so that there is only one reference needed for common code (and no code clones)
I refactored the project, and now I am trying to deploy this code to the SharePoint server (Both my local dev server through VS2012 and to the production server through WSPs). I initially tried to add the Common.dll in all of the other project's "Additional Assemblies" list (in the Package file), but this has caused all of the WSPs to fail deployment with the following error:
Cannot add the specified assembly to the global assembly cache
This is because the Common.dll is in use by the owstimer and some other services and can't be removed.
My next thought was to deploy the code as a feature and then make all of the other features dependent upon it, however, I don't know how to do this. Is there any way to have a feature that only contains classes?
Is there a better way to make common code available to multiple SharePoint projects?
Based on error it looks like you did not strongly signed the "Common.dll" assembly. As result it can't be installed in the GAC.