Hello,
I am facing a problem with a WPF project that I am working on. The application works perfectly when I build it on my local machine, but when built on TFS server, it fails at runtime with an exception 'Cannot find HomePage/HomePageView.xaml'. Attached is a screenshot of the difference between the dll built on build server & the one built on local machine. Build server gets rid of the 'HomePage' folder path for some reason. Any help on why this might be happening would be appreciated.
Also attached is a screenshot of my project layout.
Based on the screenshot You provided, it seems that some files in this project are in fact added as links and the real files exist somewhere else (the little arrows on files icons indicate this).
Please make sure that TFS build server can actually access those files in their original location while building the project.
You mentioned that the build works on Your local machine, but it's not clear if You have only rebuilt the application or use Publish option. If not, please verify if publishing the project locally works correctly.
I also saw some article describing issue when using linked files and MSBuild, but it was rather related with web applications. You can find some information about it here.
Related
I'm trying to publish a project to an Azure Web App via Visual Studio 2015. This is an MVC 4 targeting Framework 4.6.2. The publish procedure claims in VS2015 to have finished successfully, however, when the browser is launched to display the published site, it errors out with a 502 error (bad gateway/proxy) on the favicon.ico file. Obviously, that's not what's really happening.
I downloaded my eventlog.xml file from the Web App and looking at the error being reported, it's claiming that it's unable to find assembly 'EntityFramework, Version=6.0.0.0...'. However, I see the EntityFramework.dll contained within the project bin folder. But, just to see if it made any difference, I tried using Kudu to install EntityFramework from NuGet, as well as doing a nuget restore using the packages.config file that was successfully pushed up to Azure. All that did was restore a ton of files where I didn't need and the same error remains.
Has anyone else seen this issue and have any recommendations on how to resolve it? I'm not sure what else I can post to give a clearer picture of what's going one...it's not like there's any code or source, and the eventlog.xml file shows little more than the YSOD error message for a missing assembly.
Please, any assistance would be greatly appreciated!
I've had this in the past - if you read the error message carefully it says it can't load that assembly or some of its dependencies - so it may well be another dll that's missing from your application.
Use the Console blade in the portal (or the separate Kudu site and console if you prefer) to compare the bin folder contents with that on your dev/test environment and see what's missing - if you stick to using nuget packages then you shouldn't be able to go far wrong, but I think I still had problems a while ago with EF when I didn't reference the EF libraries directly from the web app, but only from a repository assembly that was referenced from the web app.
If you're not using Nuget and referencing the dependencies directly make sure the referenced dll's "copy to output" properties in VS are set correctly, such that the dll's end up being copied to your project's bin folder and included in the package that gets deployed to Azure.
Well, it turns out this one was one of those "that's not the real issue" error messages. Thanks to Russell and Karel. You input led me to verify a few things and make sure I had all things referenced properly.
Here's what I found out...our DEV SQL VM is turned off on the weekends to conserve resources (aka $$$). After sending all files from my local bin directory via FTP, I browsed to the site and received the same error. Downloading the logs, however, showed that I couldn't reach the db server using Named Pipes. Whoops...one of the connection strings (in the repository project) had not been set to the FQDN, so it wasn't using TCP/IP for the connection.
I fixed that, published the site, turned ON the sql server, and now the site is working as expected.
Moral of the story, make sure you have all connection strings set properly.
I have a cloud service project with three worker roles. Previously (VS 2013, Azure 2.5) everything published fine. When VS 2015 was available, I installed it on a clean VM and then installed Azure 2.7. I promoted my old solution and I can build and run locally just fine. I can build the cloud service project. But when I try to publish or package, I get the following error and the build fails.
Error:
Access to the path
'C:\Users[username]\AppData\Local\Temp\3xhd2e4m.wlw\roles[rolename]\base\x86\msshrtmi.dll'
is denied. C:\Program
Files\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure
Tools\2.7\Microsoft.WindowsAzure.targets 3003
When I go to Temp - there is no directory corresponding to 3xhd2e4m.wlw.
My resolution attempts so far include:
Removing the worker roles from the solution and trying to publish - fails with same error for the remaining project.
Removed read-only from temp
Tried to set everything to build x64
I really need some help since this blocking deployment and testing.
I have the same problem. According to an answer in another post (Deploying to Azure: "Access to the path ... msshrtmi.dll is denied"), the problem is related with an issue with the Azure SDK 2.7 and will be solved in version 2.7.1, supposed to be released shortly.
The problem occurs only when you try to publish from a 32-bit machine. Changing to a 64-bit machine should work.
I can't offer a specific solution as I haven't taken the plunge and upgraded to VS2015 yet, however I imagine this has something to do with the project file for the Worker Role's Cloud Service.
So, two options come to mind:
Create a new blank Worker Role Project with a single boilerplate Worker Role and check that it publishes/packages correctly. This will confirm whether this functionality works in VS2015 with Azure SDK 2.6.
If (1) works, consider adding one of your existing Worker Role Projects to the blank Worker Role Project in (1) and try the publish/package process again.
I find it hard to believe that the chaps at Microsoft have tried the upgrade path from v2.5 -> v2.6 of the SDK for Worker Roles... I've checked the v2.6 Release Notes and there doesn't appear to be any breaking changes related to this issue: https://azure.microsoft.com/en-gb/documentation/articles/azure-sdk-dotnet-release-notes-2_6/
I just got hit with this same issue and lost a few brain cells from it.
I have a defined directory in my ServiceDefinition.csdef that contains all the files I'm trying to copy out during my cloud service publish for my startup tasks, and I ended up including some .dll files as well. I was getting the same error as the OP of this question and after some time found out that I just couldn't include the *.dll files in my SourceDirectory path. I was able to include .cmd files just fine, but .dll and .config's were no good.
It wasn't good enough to exclude them from my project either, just the fact that the files were in that directory was enough to make VS yell at me.
For now I've just put all the offending files in a zip and I'm sending the zip file in my deployment, so it's a workaround, but was a painful one until I figured this much out.
Hope this helps..
I am new to ClickOnce applications. I published my application (locally, on my dev computer), installed the application using the setup.exe inside the published folder, and then ran the program. Everything was good.
I made some updates to the application, and wanted to install the new version on my computer to test it. So I uninstalled the previous version, using Add/Remove Programs. Now when I go to install the next version (from a different directory than the first install), I get the infamous "You cannot start application from this location because it is already installed from a different location." message.
I am looking into using the install-over-the-interwebs option, so that I can just update it online, for my client, but for now, I was just testing using the "From CD-ROM" install.
Basically, I'm hosed. My previous install is uninstalled, so I can't access that. And any new version cannot be installed because the installed is complaining that my previous one is still there.
My goal is to convince the computer that my previous version was indeed uninstalled. Apparently there is something lingering that is confusing it.
Thanks for your help.
So the solution for me was a 2-part fix.
First, I now update my app from a URL. You can use a local folder, or a website for this. The way I did it was publish my app into a folder of a website within the same solution. Then I publish the website to an azure site. Then to download the app I just go to that website/.
Second, I followed some advice found here: http://social.msdn.microsoft.com/Forums/windows/en-US/9e4b714e-bad4-4c62-a7ad-3c80e32d95eb/clickonce-fails-with-value-does-not-fall-within-the-expected-range?forum=winformssetup
The advice was to do this:
Mike, I am one of the previous posters here. I "solved" this (i.e. it rarely happens anymore) by turning off ClickOnce automatic version incrementing, and by making sure at every release I change the version in four places:
- assembly info for both assembly and file version
- ClickOnce version (making sure to keep the automatically increase version checkbox off)
- under Update, making sure I always set the minimum version to the same as elsewhere
I found that my version numbers didn't match in all these places -- specifically the assembly number and file version number weren't being updated inside the AssemblyInfo.cs. Once I had manually set those all to the same new number, published the app to my local folder (inside the website), published my website to azure, gone into my website via FTP and deleted old version folders in the "Application Files" folder, and downloaded the app from my website as described above, I could install and run the app without errors.
I don't know if this fix solves anyone else's problem(s) along the way, but there it is, for what it's worth.
This answer also is very helpful: http://social.msdn.microsoft.com/Forums/windows/en-US/365f8c65-b413-428e-af93-f150059a185f/cannot-runinstalluninstall-a-clickonce-application?forum=winformssetup
Thanks for reading.
I have created a simple inventory application in WPF. How should I give it to client now ?
One way what I did: I have set my AppPresentation solution as start up project and I can see all the DLLs from other solutions are added in the Debug and Release directory of this solution.
When I copy the Release folder to other drive (from D: to C:) and run the AppPresentation.exe some Error occurs about some DLL missing but I can still see those DLLs in this folder.
However when I copy the debug folder to the other drive and run the application i.e. AppPresentation.exe now I can run the application successfully with complete working.
Can I give this entire Debug folder to the client and expect that it runs perfectly on his machine ? I will ensure .NET 4.0 Framework is installed on that machine (but not Visual Studio ofcourse). Will this work ?
It will work as long as you have the required version of the .NET Framework installed on the client and all the necessary dll's have been included,
Ideally you should look at creating a Visual Studio setup project:
Using a setup project has the following advantages:
All your dll's and other files required for the application to run will be consolidated in one setup file
You can specify prerequsites such as .NET Framework which will prevent installation until all the required components have been installed first.
Users can specify exactly where on disk the application should be installed without manually copying the dlls (as would be the case in your scenario).
This is but a few advantages of using a setup project but hopefully you'll be convinced to give it a try as it is the preferred way of installing Windows applications
P.S If your setup project gets more complex consider looking at Wix
I'm currently working on a program in C# WPF. I use an external dll called Irrklang. It's made for x86 only so I set VS to compile for x86. I added the reference, set the copy local to true and set the dll as Required in the application files.
When publishing the app using clickonce I upload it. I install on two machines: my dev machine and another machine. On my dev machine things work fine. On the other machine I get the could not load file or assembly exception through my error handling I added to my app. In the event log there is a xamlparse exception.
How can I solve this when everything works fine on my dev machine. I tried Dependencywalker but that doesn't show anything and I made sure the dll is in the folder of the executable. I ask this question again here on stackoverflow, the last time someone made me an empty app with a reference to the dll and he installed it on 3 other machines and it worked fine. I published his app like I did with my own and it shows the exact same problem!
Please help me out
UPDATE: I was thinking about it but your comment beat me to it! :D I program .net 4 Extended and it is set as a prerequisite. VS C# Express 2010.
Well, no specific advice then. It sounds like you just need to some old school trial and error... Whiddle the app down to something that will distribute correctly with ClickOnce and keep adding functionality until it doesn't!