We have a problem since converting our products to .NET 4.0 and using the updated code access security model. Basically we have component libraries that may or may not be installed to the GAC on a machine.
If someone makes an XBAP with default partial trust settings that uses these libraries and an end user installs the XBAP (which deploys the libraries during its install), it works fine if our libraries weren't already in the GAC.
If they were in the GAC, the XBAP will fail at run-time with security exceptions. I believe the problem is due to this:
http://msdn.microsoft.com/en-us/library/aa970906.aspx
When managed assemblies are installed into the global assembly cache (GAC), they become fully trusted because the user must provide explicit permission to install them. Because they are fully trusted, only fully trusted managed client applications can use them.
It seems that since they get pulled from the GAC, their security is elevated more even though they are the exact same .dlls deployed with the XBAP. But in that case, everything breaks.
Is there any way to work around this issue short of adding the AllowPartiallyTrustedCallersAttribute to all the libraries?
Or is there a way to prevent an XBAP from looking in the GAC for an assembly and just using the exact copy of the reference it is deployed with?
Thanks in advance for any assistance.
In visual studio, solution explorer, click on the reference and try setting the property "SpecificVersion" to true. It should just look in the path specified and the version specified when referencing and not go hunting for the latest in the GAC.
See .net reference specificversion true or false?
Note that if you add a new version of your reference, you'll have to remove your current reference, it won't automatically replace it.
Related
I have built one windows forms application and I published for client installation. While installing the setup file, it should ask the user to select the installation directory path; instead, it's installing in default path as below :
C:\Users\Mysys_t\AppData\Local\Apps\2.0\434YBBVC.Z2H\TNYPR09N.1JZ
Is there any settings to do this, so that, while installing, user is able to select the installation directory?
In general, the answer is no. See a related MSDN forums discussion among other online references that explains why: ClickOnce was designed to automatically manage installation directories to prevent deployment collisions.
Now...the referenced MSDN forums discussion also links to one way to possibly work around this. Certainly anything is possible with some ingenuity and work (e.g. publishing a setup wrapper with ClickOnce to leverage ClickOnce's auto updates but use indirection to control where your actual app ultimately gets installed); but this is not possible using ClickOnce "straightforwardly".
this can be achieved by
Creating an MSI Package for C# Windows Application Using a Visual Studio Setup Project
pls follow the link below :
http://www.c-sharpcorner.com/UploadFile/1492b1/creating-an-msi-package-for-C-Sharp-windows-application-using-a-v/
I have VS.NET 10.0.40219.1 SP1 in 2 computers and when I create a new C# Winform app only do it with Properties/Build/Platform x86, and the target let me choose AnyCpu/x64, but can't set it in the configuration (however, libraries work fine).
If I try to change it in the project file manually, I get a lot of nasty errors. Is this normal behavior, a bug or a problem in my installation?
P.D: When I change manually the project, this happend:
Warning 1 The OutputPath property is not set for project '*.csproj'.
Please check to make sure that you have specified a valid combination
of Configuration and Platform for this project. Configuration='Debug'
Platform='x86'. This error may also appear if some other project is
trying to follow a project-to-project reference to this project, this
project has been unloaded or is not included in the solution, and the
referencing project does not build using the same or an equivalent
Configuration or
Platform. c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
When I reopen the project, ALL the references become invalid
It is normal for Visual Studio to create WinForms projects with just an x86 platform. I have no idea if that's because historically x86 was the only platform type or because x86 is the most commonly used value or for some other reason.
It's also normal to have problems when the project file is manually modified, try to avoid doing that where possible.
To create another platform configuration in a C# project
Select Build | Configuration manager
Select <New...> in the Active Solution Platform field
Select the new type you want
Click on OK
Visual Studio used to create AnyCPU apps by default. I think both VS2005 and VS2008 did this, though they may have changed it for VS2008. Here's what happened: a lot of AnyCPU apps ended up broken on 64-bit systems, because they were built with dependencies on 32-bit libraries. If you tried to run an AnyCPU app that had a 32bit dependancy on a 64bit system, you got a 64bit process that would crash as soon as it tried to load your 32bit dll.
To fix this, the default was changed to use the x86 option. If you want to use AnyCPU, you must now setup the environment for it.
I'm developing a small WinForms program for home use - I have no intentions to releasing it anywhere.
Running it on my development machine, where I have Visual Studio and .NET and whatever else installed, works but deploying it on my PC, where I might not have all those frameworks, doesn't. I'm using some library written in C++ so I'm assuming I'm going to need some version of Visual C++ Redistributable, but I'm not sure which? And I'm not sure if that would be all. So, how can I determine an application's software prerequisites?
I used Dependency Walker and I got a message IEHIMS.DLL - Error opening file. The system cannot find the file specified (2), but that's all I could make out; there is so much information I'm having trouble make sense of it all. Besides, according to a quick google, IESHIMS.DLL has something to do with Internet Explorer, so it shouldn't really matter.
Thanks in advance to anyone taking to the time to consider my question.
Kind regards
For framework you can set the prerequisites for your application by going to project properties -> Publish -> Prerequisites. So now, if the required framework is not installed on the deployment machine, the setup will prompt for an install.
Now, for other dlls you are using, copy those dlls to your bin folder of the project and add the files while creating setup. This will solve the problem.
I've been facing a deployment problem.I've built a WPF application with visual studio 2008 and created an installer(msi) which works fine.But then it's pain to add automatic update to it. i've seen this article at windowsclient.net but it seems to be pretty old but could have been the perfect thing for me.Then i looked at the .Net Application updater block v2.0 which uses enterprise library june 2005 and for some reason it's not installing on my machine.
I thought i will need to use a more recent Enterprise library so i installed and compiled Enterprise 4.1(october 2008) but nothing better happened.To i decided to give a try to CLickonce deployment.After struggling with it, it was almost perfect.I realized that when i was testing the updates provided by the clickonce on my machine which is XP i didn't notice the need of having sqlite dll in the GAC. surely it was already there.I noticed it when i moved to vista that there is a problem.After checking the net i know it's impossible to add a dll to the Global Assembly Cache.
Now i'm stuck, i think i've hit a wall.Can any one share some of his experience? I'm willing to try the updater block if i can get help.
Thanks for reading this!!
(Won't fit in a comment)
Here's something helpful -- you can deploy the SQLCE dll's locally, instead of installing as a prerequisite, which makes it easier to deploy. Check out this article.
This is another useful article: how to keep your data safe from ClickOnce updates.
This will make more sense if you check out this thread. I have a post in this thread that has two links in it. One points to the ClickOnce way of handling database deployment, the other to a thread that is essentially the same as the blog article above.
First, you can't use that updater block. It was for .NET 1.1. It was marked obsolete when ClickOnce deployment was added in .NET 2.0.
You probably don't need to install that dll in the GAC. In many cases, you can just include it in the deployment, and it will find the local reference and use it. It just depends on the dll. So here's what I recommend you try:
Add the dll to your project. Set the 'build action' to 'none'. Set 'copy to local directory' as 'do not copy'.
Delete the reference in your project to that dll, and re-add it. But instead of picking it from the GAC, browse to the one you just added to your project and select it. On the reference properties, set 'copy local' to 'true'.
Now when you run it, it will access the local copy instead of looking for one in the GAC.
Like I said, this works great in some cases. It works for SQLCE and DirectX, but not for something like Infragistics. Some assemblies really do have to be installed in the GAC. The only way you will know is if you try it.
If you DO end up having to put it in the GAC, you can create an MSI to do that and deploy it as a prerequisite to the ClickOnce application. So you can still use ClickOnce for your main app.
I built a WPF application in VS.NET 2008 using ClickOnce deployment. It ran great on any machine that had VS.NET installed, but my business users received an error: "Unable to install or run the application. The application requires that assembly Microsoft.Windows.Design.Extensibility Version 3.5.0.0 be installed in the Global Assembly Cache (GAC) first."
I was surprised to discover that this dll is not part of the standard .NET 3.5 SP1 client installation, but somehow, my application thought it was needed. I checked my Publish tab for the project and it showed up as a prerequisite.
Oddly enough, I was able to just remove this (and all of the other Microsoft.Windows.Design.* dlls) and it just worked everywhere. I removed them from my project entirely, and everything was fine.
Can someone explain why the VS.NET 2008 project wizard forced these to be included in the project, and more importantly, why ClickOnce thought they needed to be on the client machine to run?
This is just a curiosity question, but I'm sure I'm not the first to be bitten by it. Hopefully, this post will at least save someone else the headache.
Try to remove all references to *.Design.dll. In my case it was WPFToolkit.Design.dll.
This is old and the OP is gone, but I ran into this today, so I thought I'd mention that my solution was removing a reference to one of the WPFToolkit references that ends with .Design.
I had referenced System.Windows.Controls.Input.Toolkit, but also had a reference to System.Windows.Controls.Input.Toolkit.Design, which should not have been there. Removed it, and all was right with the world again.
A way to find out the code that is loading the assembly is explained here:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/755272f6-0e79-4a6d-ae50-4412d0f2bc4c
I found that I was using the SelectionCommands.Clear property which is inside the Microsoft.Windows.Design.Interaction namespace inside the Microsoft.Windows.Design.Extensibility Version dll.
Beats be why this dll isn't included in the .NET 3.5 install.