How do you set the assembly name for a web application project?
The following page in the MSDN document says ‘Because this compilation model creates a single assembly, you can specify attributes, such as assembly name and version’. http://msdn.microsoft.com/en-us/library/aa983464.aspx.
However I can’t work out how you can do this!
Right click on the project in the Solution Explorer and select Properties. On the Application tab, there's an Assembly Name text box, where you can set that.
Related
My solution has two projects. A class library to generate data from an Entity Framework .edmx file via a repository class. The App.Config file connectionString matches the Web.config in my second ASP.Net 4.0 web forms project.
I modify BOTH connectionStrings to point to the test database (DataSource=TestDB) when deployed to the test server. When deployed to the live site I modify both to point to the live database (DataSource=LiveDB).
At the top of Site.Master I display in red letters "You are connected to the TEST database" in a label control. I conditionally toggle the .Visible property of the label if (context.Connection.DataSource.Contains("TestDB"))
During development I noticed something strange. When Web.config points to TestDB, if I forget to make App.config match (and it points to LiveDB) the "connected to TEST" warning appears but data from LiveDB displays.
This tells me the repository (class library) uses App.Config but a data context created in the web forms project uses the Web.config connectionString. Is that correct? I'm concerned that live data will be updated incorrectly if I deploy to the test site and forget to point App.Config to TestDB.
So my question is, in this scenario... What is the best way to display a notification "connected to test database" that is always accurate?
By default a class library will not be using any app.config file.
It would use the .config file that is in the context of the application using it - in the case of a web application that would be the web.config file.
When the app runs, it's using the one in web.config, no matter where the context is created.
Why not set up the firewall on your live application to prevent access from (a) anywhere except the live webserver, or (b) especially your test location?
I developed an ASP.NET MVC 3 web application and it's working correctly locally, but not on the server:
Line 18:<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
How do I fix the fact that the server can't find this assembly?
It's looking for a GAC'd assembly reference to that assembly. Do you have that assembly installed on the server? If not, you need to set it to bin deploy.
Here's how you do that:
To set the Copy Local property to True
In Solution Explorer, double-click the My Project node for the project.
In the Project Designer, select the References tab.
Select a referenced component in the References list.
The properties associated with that reference appear in a list in the Properties window.
Select Copy Local from the left-hand column, and then click the arrow in the right-hand column to change the value to True. (Source)
To set up your project to bin deploy, follow these instructions laid out by Scott Hanselman.
right click on project in solution exploret.
select Add diployable dependencies
checked Asp.net MVC and click ok
I have a solution which contains multiple WAPs (Web Application projects).
Every WAP has it's own Web Deploy project in order to be able to precompile these sites.
On one of the web app we are created a new WCF file with
AspNetCompatibilityRequirementsMode.Allowed
In debug mode it is working ok, but if i switch to release it crashes:
(we are using msbuild to create the deployable versions)
Could not load file or assembly 'App_Web_*****, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
I found some explanation in this link: WCF service
WCF stores the list of referenced assemblies into the customString
attribute in the build result (service.svc.cdcab7d2.compiled),
including App_Global. It seems there is an incorrect assumption here
that those assemblies will always be there, which is not necessarily
the case in Web Deployment Projects (aspnet_merge) where assemblies
will be merged. After the merge step, the assemblies are actually all
merged into a single assembly (let us say MyWebSite.dll) as we
selected that option in WDP. ASP.NET only updates the .compiled files
it knows about, so App_Global.asax.compiled actually has a correct
reference to MyWebSite_Deploy.dll instead of App_Global.dll. Original
assemblies are removed after the merge step. WCF reads the list of
assemblies previously stored, and throws when it cannot find
App_Global
List of solutions i've tried:
1.Check 'Allow this precompiled site to be updatable' - not worked
2.Remove manualy the App_* reference from service.compile file
(It worked but it should be another solution)
3.Add fully qualified name for the service/factory in .svc
The service has a fully qualified name.
4.tried to set this key:
<SourceWebPhysicalPath>..\..\ProjectName</SourceWebPhysicalPath>
following these instructions
5.<compilation debug="false" batch="false">
Tried this to set to web.config using these instructions
6."Merge All outputs to a single assembly"
i haven't tried this because it requires to register all the used assemblies to GAC and means we need to change the deployment logic.
I don't want to delete the asp.net temporary folder because it stops the application and it is inacceptable
I also found Scott Gutthrie link but it's from '07 it should made it's way to asp.net 4.0
Additional Info
The service is placed: ProjectName\WebResorce\Service.svc ,
<%# ServiceHost ... Factory="SolutionName.SharedWeb.WadoLabsServiceHostFactory" %>
where the SharedWeb is a Shared Web project
Do you have any other ideas?
Thanks in advance
The following setup worked for me:
In the svc file, specify a qualified name of the service, as <%# ServiceHost ... Service="<Namespace>.<ServiceContractClass>, <AssemblyName>" CodeBehind="ServiceContractClass.svc.vb" %>
(Can't remember why it was required, but) I made sure that the Namespace and the AssemblyName are different.
The trick is to specify the qualified name, including the AsseblyName.(The assembly name that is specified in the project containing the service, not the Web Deploy Project).
Also note that there is a space between the comma after the class name, and the AssemblyName.
Why don't you implement the WCF services in a separate library project inside the same solution, and simply reference that project from your web app(s)? That way they would stay out of the pre-compilation process, and you could work with predictable type names inside the *.svc files. Plus, this would probably also give you a cleaner solution structure.
I've just gone thru a large-ish project and renamed A LOT of namespace directives. Everything works fine on my developer box - deploy it to stage and I get:
Compiler Error Message: CS0433: The type 'ASP.usercontrols_pageheader_ascx' exists in both
'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\89252a5f\7305b927\App_Web_hodsbmv3.dll' and '
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\89252a5f\7305b927\App_Web_pageheader.ascx.6bb32623.bs4iljip.dll'
Yuck. Very similar to this: Deployment Project dlls cause ‘type x exists in both’ errors, but must be coming from a different cause.
I have none of the problems I've seen mentioned in other articles (App_Code / CodeFile directive). Worked out why it works on my machine: the website has no problem when it is in a vdir. If I remove the "PageHeader" usercontrol from the masterpage it lives on everthing is fine. If I rename "PageHeader" everything is fine. Updated: renaming the usercontrol doesn't help.
I'd had a look at the assemblies mentioned in the error in reflector; App_Web_hodsbmv3.dll contains dynamic classes for all the usercontrols in my project. \App_Web_pageheader.ascx.6bb32623.bs4iljip.dll' contains the same code just for the PageHeader usercontrol. Why would ASPX decide to create the same class in two assemblies?
Are you using web deployment projects?
Try deleting the asp.net temporary directory for this application (located here: C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\yourappname). You have to stop the app pool for this site before you delete the dir.
Try the setting to merge all outputs to a single assembly to see if it makes any difference.
..update..
"Merge to create a single assembly for all the Web UI content files by using Aspnet_merge.exe with the w option."
http://msdn.microsoft.com/en-us/library/bb397866.aspx
The winning answer goes to this forum post: Publish web site: TYPE exists in both temporary ASP.NET assemblies
If you're getting this error, review all of the directive attributes and code-behind class names in your web user controls and web forms.
Because I'd changed all the namespaces in the project I'd botched in asmx. I had an Inherits in the ASMX that didn't match the class in the code behind. Somehow this resulted in the compilation batching putting some (not all) usercontrols into their own temporary assemblies, AND the group assembly.
Where are assembly refernces stored for a web application?
In a Web Site, I see assembly tags written to the assembly node in the web.config when you add a reference. I am just curious as to how the Web Application Project makes the connection to get the correct local dll?
I manually add the reference and the application builds, but the dll is not imported into the BIN folder, and the assembly nodes are not created in the web config as they are in a Web Site. I do a solution search for the text 'assembly="SomeAssembly..." and no results are found.
I am just curious as I am trying to centralize updating assembly references as a 3rd party control vendor puts out hotfixes on a regular basis and we end up having to run around and update all the individual page refernces to the assembly. I was able to do this effectively in the Web Site project, but I am fairly new to Web Application Projects. Any advice or links would be appreciated. I guess I'm looking for tips on assembly & control reference management for ASP.NET Web Application Projects.
Like most Visual Studio projects, references are kept in the project.
There are two kinds of reference:
Project References are references to another project in the same solution. They look like this:
<ProjectReference Include="..\VBClassLibrary1\VBClassLibrary1.vbproj">
<Project>{045D7D9F-8E44-4C4B-95F8-620E86593C5B}</Project>
<Name>VBClassLibrary1</Name>
</ProjectReference>
File references are references to an arbitrary file on disk:
<Reference Include="System.Core">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
If you expand the References folder and click on a reference, then look in the Properties window, you'll see that both kinds of reference have a "Copy Local" property. For project references it defaults to true, for file references to false (though maybe that's only if the file is in the GAC). Changing the default adds:
<Private>False</Private>
Since the assembly was not imported to the BIN folder, and your application works, I assume that it is stored in the GAC (global assembly cache) and marked as "copy local=false" in the reference properties. You don't see the reference to the assembly in the web.config, since your code behind assembly - YourApp.dll (which is always created for web-applications), contains a standard assembly reference to that assembly. When you run your application it loads the assembly from the GAC.
Those "missing" dlls are probably in the Global Assembly Cache and are available to all .NET applications.
You can add control references to the pages/controls section of web.config, which will apply to all pages in the application.
I had the same issue, deleting .vs folder in the directory of the project solved the issue for me as it forced the recreation of .suo file which (though bite code) had reference to the web.config file in the wrong directory