We have a project management application written in VB.net. When running this application from a 32-bit machine or from within the Visual Studio IDE on a 64-bit machine, it looks for the correct configuration file (i.e. MyApp.exe.config). However, when running this app from outside the IDE on a 64-bit machine, it looks for MyApp.config and fails to find it.
Obviously I can copy the correct config to the badly named config, but we're at a loss as to why this behavior is occurring in the first place.
This is a windows application written in the 2.0 framework. No web.config file is associated (as I have found some references to a similar issue with web.config files that didn't apply).
Any guidance or suggestions is greatly appreciated.
Edit: I also should note that this is the only application this is occurring on. If I create a new vb.net application using the same libraries we use for config management, it works fine. Also, of some possible relevance, the projects are being built targeting the x86 CPU.
What I'd do is on 64 bit at install time I'd do CreateHardLink("MyApp.exe.config", "MyApp.config", NULL)
CreateHardLink is P/Invokable.
Related
Using Visual Studio 2017 (RC), I am trying to setup a project that uses ASP.NET Core, but with the .NET 4.6.2 library.
This is a supported configuration:
Visual Studio will then create a default project; but it doesn't run:
This is without changing a single line in the project: the VC2017 template just does not work.
I tried the following:
- Different versions of the .NET framework
- x86, x64, AnyCPU
- Clear the NuGet cache
- 'Repair' options on Visual Studio's installer.
My understanding is that the error is a x86/x64 mismatch. But since I didn't change a single file from the template, there has to be something else wrong.
Installing ASP.NET Core on .NET Core works perfectly, so the problem is limited to using the regular .NET framework.
Any ideas?
I have the same problem too. But I just found the solution.
In ".csproj" I change some things:
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<!--<RuntimeIdentifier>win7-x86</RuntimeIdentifier>-->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier></PropertyGroup>
And I enable the 64-bit version of IIS Express.
I had problems like these when I restored stuff to a new laptop.
I mindlessly I copied files from my old profile directory to a directory with the same name, but that isn’t a profile directory on the new machine.
A part of this process involved a cloud backup service that my wife bought for me but that I never actually set up right. That also copied files to new locations without my paying attention to what was happening.
I still don’t know (yet) exactly how the machine keeps track of which versions of frameworks and tools to use in the various application directories, but I can report what I did that finally allowed me to create new .NET Core apps on the new machine.
I deleted everything in this directory that was older than today.
%USERPROFILE%.nuget\packages
Again, pretty mindless. I don’t know, (yet) if all that was necessary. Maybe just deleting one or two of the files/directories would have worked. Regardless, I was very happy to see that I could create and develop .NET Core apps on my new machine.
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.
Is it possible to make an vb.net application portable?
It is portable - build your .exe and copy it on your flash drive. Assuming it will be run where there is .net framework, there is no problem!
EDIT: A similar topic here: Writing USB Drive Portable Applications in C#
"portable" has more than one meaning, but if you mean a program that could also run on linux or mac than you need to think mono. Specifically, look at their migration analyzer.
Depends on what you mean by "portable". Certainly, you can build them without external dependencies on things like config files, registry settings, etc. You'll still need the .NET runtime installed on the target computer, though.
I seem to recall that you can use vb.net to write Silverlight apps; once compiled, this should be fairly portable (onto all Silverlight / Moonlight enabled browsers).
Of course, if you talk about web apps, the client (html) should already be portable, regardless of the server.
Whether it's a desktop application or a web application, the .Net framework needs to be installed on the machine that the app is run on. Generally, the .Net framework is installed with Windows.
It has to be the same version of the .Net framework as the app was developed in (1.0, 1.1, 2.0, 3.0, 3.5). Which version of the framework is installed depends on the version of Windows.
Just a thought!
Maybe you can make your app executable the normal way (with setup) and then make it into a portable application online using service described at
http://www.abtevrythng.com/2011/12/make-portable-applications-online-for.html#ixzz1flSBi6dZ
You can try to use the online portable app "converter" Cameyo to do it. Just install the Cameyo app, launch it, then install the application you made.
You must use VS 2015. Make all your reference dll's to be local copied. Build your solution (with no deploy file extension (publish-> options->deployment))and merge the exe file with your dll with ilmerge ( http://www.microsoft.com/en-us/download/details.aspx?id=17630 ) (download ILmerge-GUI too) from the Microsoft web site. And have good luck