I have a service which uses multiple dlls using reflection method . These dlls are loaded dynamically but once window service runs i am not able to update the dll or delete them etc .
I see Shadow copying as a viable solution . but i cannot find exact syntax if i want to set ShadowCopyfiles property of current appdomain to true.
I am using asp.net , and framework is 4.0
Here is a link to setting it up, hope that helps.
Related
I created a new .NET 6 Blazor Server-side project and made a couple of changes. I have a couple of files using CSS isolation (like Contact.razor + Contact.razor.css).. In the _Layout.cshtml page the template added the following:
<link href="CustomerPortal.styles.css" rel="stylesheet" />
Where CustomerPortal is my Project Name. I can see the file is generated correctly under "CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\projectbundle\CustomerPortal.bundle.scp.css" and "C:\Data\Git\WebApps\CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\bundle\CustomerPortal.styles.css"
BUT when I run the project, both with Kernel or IIS Express, I get a 404 not found for the CSS, if I try to manually navigate to the CSS I also can't find it. Any ideas? My csproj doesn't have any flags that would affect it.
Edit:
There is a new extension as part of the minimal setup in .NET 7, and backported to newer versions of .NET 6 as well.
Both in .NET 7 and .NET 6 you can now do:
builder.WebHost.UseStaticWebAssets();
Old answer:
You've got a couple options here to resolve this depending on the approach you want to take. I think we've figured out why it's happening, but UseStaticWebAssets() seems to not be supported for the new minimal startup code. So, here's your options I can think of off the top of my head.
Migrate your code back to the "old" way of doing application startup. This is still a supported and completely valid approach as there's edge cases that aren't supported (like this one).
Pass a new WebApplicationOptions to the CreateBuilder() method and, depending on environment, look for the static files in a separate (and correct) location. See some examples here.
With the existing builder, check the environment and use the StaticWebAssetsLoader to load static web assets.
A complete example of #3
if (builder.Environment.IsEnvironment("Local"))
{
StaticWebAssetsLoader.UseStaticWebAssets(builder.Environment, builder.Configuration);
}
That being said - I'd imagine they'll plug this hole eventually and provide parity for UseStaticWebAssets(). You can see the progress of this effort in this open GitHub issue.
For anyone else...
I had the exact same issue with a .net 6 blazor server app. For me it came down to the fact that I had changed the project name but the reference to {project}.styles.css in _Layout.cshtml was still pointing to the old project name.
Simply updating {project} here to the correct project name fixed my issue.
When I encountered this error, it was because I'd named my MVC project with a hyphen: htmx-spike.
When I generated the project from a template (dotnet new mvc -o htmx-spike), the tooling renamed the namespace to htmx_spike—with an underscore instead of a hyphen, because hyphens aren't allowed in C# identifiers—and used that modified name as the CSS filename in _Layout.cshtml.
However, it turns out that in this case the CSS location actually still corresponds with the project name, with the hyphen. So the auto-generated code is incorrect, and was causing the 404 to be returned:
Once I renamed the file in the link element to the correct name with the hyphen, everything was fine.
I had the same issue with a component I imported from another project. I solved it by closing all instances of Visual Studio, deleting the hidden folder [.vs] from the project folder, and then restarting the project in Visual Studio. On restart, Visual Studio recreated that folder and imported CSS file(s) were included.
EDIT: I found a way to get it to work locally, but on Azure I still get System.IO.FileNotFoundException on that assembly.
My question might seem like a duplicate to this question here. But it is slightly different, I have already tried that solution and it did not work. Here are the details.
I have an ASP.NET MVC App that has a Reference added to a third party CLR DLL. That third-party DLL requires a native DLL which it invokes. Now if I had control over where the Shadow Copying occurs and what is copied, I would be in paradise. The Shadow Copying misses copying that native DLL despite it's Build Action set as Content and Copy To Output Dir set as Copy Always.
So I searched internet and ran into this discussion on SO, which is same as what was mentioned earlier. I tried adding the code that sets the PATH Environment Variable inside Application_Init and Application_Start of Global.asax, I set the breakpoints in both the methods and to my surprise I get the ASP.NET Error Page before it even hits the breakpoint. This leads me to believe that the referenced assembly at the time of binding hits the native DLL and invokes it. What can I do? Can I delay the reference binding somehow?
EDIT: Yes we can, I opened the Referenced DLL's code which was written in Managed C++, I adjusted the linker setting to Delay Load the Native DLL and now my Application_Start executes first. Yayy! but that does not solve the same problem I am having on Azure
Here is the test solution with DLLs
Here is the source code for the Native DLL
Here is the source code for the Referenced Assembly that uses the Native DLL
To download the Native DLL distribution, Go to their distribution page, choose the windows archive with the bitness you desire (I am using 32-bit), and you will find amzi.dll inside APIs/bin directory.
Actual problem was the wrapper DLL not recognized on Azure server because of lack of support of earlier frameworks and toolsets, as well as Debug CRT.
I used XDT/Application_Start to set the PATH environment variable to include the location of my native DLL
I upgraded my Managed C++ Wrapper DLL to use Toolset 14.0 and .NET 4.6.2
Used Linker Setting of /DELAYLOAD on Managed C++ Wrapper DLL
After downloaded the DLLs and source code which you provided, I found that the native DLL depends on x64 platform. Firstly, we need to change the Platform property of our web app to x64 using Azure portal. If the platform button is disabled, you need to scale up your web app plan to Basic level plan or higher level.
In addition, the original path may end with “;”, so we need to check whether it contains “;” and append right content to it. Code below is for your reference.
string path = Environment.GetEnvironmentVariable("PATH");
Trace.TraceError(path);
string binDir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Bin");
Trace.TraceError(binDir);
if (path.EndsWith(";"))
{
Environment.SetEnvironmentVariable("PATH", path + binDir);
}
else
{
Environment.SetEnvironmentVariable("PATH", path + ";" + binDir);
}
To test whether the path is set successfully, you could add a page to test it.
public ActionResult GetPath()
{
string path = Environment.GetEnvironmentVariable("PATH");
return Content(path);
}
After path is set, the native DLL can be load successfully on my side.
On my end I added a throw new ApplicationException("Test") at the beginning of Application_Start and instead of getting my test exception, I was getting the DLL load error.
It means the setting path code will not executed. To fix it, you could remove the native DLL reference from your web application. Now your application could work fine and set the path environment variable. Then you could add the native DLL reference back.
Another way to do it is that we could create a webjobs and set the path environment variable in webjobs and deploy this webjobs before deploying your web application.
I am using 32-bit distributions, my native dlls depends on x86/32-bit.
If you use 32-bit distributions and the platform targets of your CLR DLL and your web application are set to "x86 or Any CPU", you won't need to change platform to x64 in web app. Please change it back to x86.
I have an asp.net application which uses some web services(WCF) in the solution exporer ( Through add reference). I can see that end points are defined in Web.config
Now i do not want to touch the web config in the production and i have two questions.
1. What dll should i be putting on production - Released one or debug dll.
2. Whatever is taken as reference (WCF) in our asp.net applicaiton. I hope only defining end point is sufficent assuming that i havent changed anything in the WCF Service.
I will appreciate if someone can guide in this regard.
Thanks in Advance- New to .net :(
Specific to your questions, here are the answers
1) On production servers "Release" build (dlls) is the best bet because they are optimized for performance. you don't need to add the reference again, unless there is some code change (which changes the wsdl of service)
2) End points will not be changed, therefore just by copy new service dlls, you should be good to go. The types in config file remain the same as in WCF service.
Check in your VSS for Configuration Manager,which one you are pointing it.It can be release or debug.
Whichever is choosen,you have deploy the corresponding one.WCF service,defining end point is fine.
I have inhherited a vs2010 c# web project (asp.net). It has a web reference to a web service. There's been a slight change to the service - a new operation has been added. I'd like to update the proxy class so that i can call the new operation but i can't find the class. I seem to remember there used to be a "show all files" button in solution explorer that would reveal the proxy class but i can see no sign of that. Unfortunately, i'm not able to refresh the proxy by pointing it at the web service metadata wsdl because vs is no longer installed on any pc that can reach the web service. Anyone know where i can find the proxy class?
It doesn't matter you can't find it in Visual Studio - you can always locate a proper file in your filesystem, under the project directory.
Problem was, the app was running - doh!
Yes, you are right. There is a "Show all files" icon in the tool bar. It will only be available when you have a project selected, so you want to select the web service's parent project:
Expand the service reference and under it the file called Reference.cs is the proxy class.
You should NOT be hand editing this though. You should make the changes to the service and then regenerate the proxy using the Update Service Reference right click option. But then if you really can't do that as you say, then just hand edit the file. But beware that any changes you make will be lost if someone does regenerate it again in the future. Very Risky! (I prey you are using source control)
There is a WSDL.exe command line tool.
Copy and execute this command line tool in the PC where you can have access to the WebService, it will generates the proxy again and you can replace them with the files in your project.
http://msdn.microsoft.com/en-us/library/7h3ystb6(v=vs.80).aspx
This question is a follow up to my question about sharing resources between web applications, because I have not yet found a good solution.
I have a web application with user controls and resources that are shared by three other web applications.
Solution
|
+-CommonControlsWebApp
| +- resources
| | +- images
| | +- scripts
| | +- stylesheets
| +- UserControls
|
+-WebApp1
|
+-WebApp2
|
+-WebApp3
This is what I know this far:
I can not compile CommonControlsWebApp into a single dll since I am creating user controls. This is only possible with custom server controls, where everything is in the code-behind file. So I need a way to share the ascx files between the four projects.
Copying the files from CommonControlsWebApp into the three other projects does not update their files in the solution explorer. I would have to 'add exting items' all in all three WebApps when a file is added or renamed in CommonControls.
Changing to the Web Site model would remedy this, but I am worried about the compile time for WebApp1-3 if I do this.
'Add as link' does not work for directories.
I could use Subversion to share the files between the projects, but i believe that this would require me to check the files in and out again all the time if I am developing a user control that I have to test through one of the WebApps.
Can it really be true that ASP.NET does not have a good solution for this? How are you guys organizing large web applications?
Edit: Thanks a lot for all the answers. I am going to copy my user controls with a build event for now, and then see if we have time to refactor them into server controls.
The way we do it at my present company is to make sure CommonControlsWebApp
is a WebApplication, not a web site. Then you use names for the folders that would help identify it as the common ones that are distinct from the individual web apps. (CommonUserControls instead of just UserControls)
In your other web apps, you create a virtual directory to the CommonUserControls, etc, and add a file based reference to the CommonControlsWebApp.dll
This requires you to use IIS for development (not casini), and Visual Studio won't believe that the controls really exist, but it will work at runtime, and you can build just fine with only warnings about blahblah.ascx or blahblah.master path invalid.
If you do use common master pages and Visual Studio 2008, you will need SP1 for 2008 and use a __fallback.master in the root of the individual web projects to go in to design mode.
However, I saw this on another thread, and I am going to look into doing more like this:
http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx
You could compile it into a dll
Turning an .ascx User Control into a Redistributable Custom Control
Brief Outline of the Steps
The basic steps to make this happen
are as follows:
Write your user control as you normally would, typically using the
Visual Studio designer.
Test it using a simple page before trying to deploy it.
Deploy the application to precompile it.
Grab the user control's assembly produced by the deployment step, and
you're essentially done: You have your
custom control.
Finally, use your custom control in other apps
Further info here http://www.nathanblevins.com/Articles/Compile-a-Web-User-Control-into-a-DLL-.Net-c-.aspx
In order to share controls between web apps, the only way I found was to either rewrite them into server controls or to use virtual directory to make the user controls actually in folder be in each project.
Unfortunately, asp.net doesn't really have a good solution for this. The same is true for sharing master pages.
You might consider using source control and sharing your controls at that level. We do this for a sizable user control library and it works quite well.
Using SourceGear Vault but you should be able to do this with any source control product.
Check this post for how to solve this issue.
The basic idea is to change your project to have a prebuild step to copy over the .ascx files to a subdirectory of the web application. Then just refer to those copies when using them. Of course you also need to reference the UserControls assembly as well.
One option is to try "Add existing" and in the dialog that appears, the OK button has a drop arrow next to it, change it to Add with a link.
If that doesn't work, rewrite your controls as Custom Controls.
It will take a little while, but will make it much more maintainable in the future.
hey this is not the best way to do things but i used to do this in my asp.net 1.1 days - you can try this - shift your user controls into a seperate project, and publish this project as a virtual directory under iis
as long as you are not using codebehind - your updates would be cool (only update shared user control folder)
if you do use codebehinds - redeploy the user control dlls into different projects
once you are done with this - map these user controls into all projects using their virtual paths
check these links - http://aspadvice.com/blogs/ssmith/archive/2006/10/05/Tip_3A00_-Share-User-Controls-Between-Applications-in-ASP.NET.aspx
AND
http://www.123aspx.com/redir.aspx?res=30887