I have a windows forms application that is deployed to two different locations.
Intranet - ClickOnce
Internet - Installed on a citrix farm through Windows installer
I display ClickOnce version number for click-once deployed versionApplicationDeployment.IsNetworkDeployed.
if (ApplicationDeployment.IsNetworkDeployed)
return ApplicationDeployment.CurrentDeployment.CurrentVersion;
But for the non-click application, I am not sure how to retrieve clickonce version unless I hardcode the version number in assembly info.
Is there an automatic way of retrieve ClickOnce version number for non-clickonce deployed version?
Add an assembly reference to System.Deployment to your project.
Import the namespace in your class file:
VB.NET:
Imports System.Deployment.Application
C#:
using System.Deployment.Application;
Retrieve the ClickOnce version from the CurrentVersion property.
You can obtain the current version from the ApplicationDeployment.CurrentDeployment.CurrentVersion property. This returns a System.Version object.
Note (from MSDN):
CurrentVersion will differ from UpdatedVersion if a new update has
been installed but you have not yet called Restart. If the deployment
manifest is configured to perform automatic updates, you can compare
these two values to determine if you should restart the application.
NOTE: The CurrentDeployment static property is only valid when the application has been deployed with ClickOnce. Therefore before you access this property, you should check the ApplicationDeployment.IsNetworkDeployed property first. It will always return a false in the debug environment.
VB.NET:
Dim myVersion as Version
If ApplicationDeployment.IsNetworkDeployed Then
myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion
End If
C#:
Version myVersion;
if (ApplicationDeployment.IsNetworkDeployed)
myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion;
Use the Version object:
From here on you can use the version information in a label, say on an "About" form, in this way:
VB.NET:
versionLabel.Text = String.Concat("ClickOnce published Version: v", myVersion)
C#:
versionLabel.Text = string.Concat("ClickOnce published Version: v", myVersion);
(Version objects are formatted as a four-part number (major.minor.build.revision).)
No I do not believe that there is a way. I believe the ClickOnce information comes from the manifest which will only be available in a ClickOnce deployment. I think that hard coding the version number is your best option.
I would simply make the assembly version of the main assembly the same as the CLickOnce version every time you put out a new version. Then when it runs as a non-clickonce application, just use Reflection to pick up the assembly version.
Try thread verification:
if (ApplicationDeployment.IsNetworkDeployed)
{
if (ApplicationDeployment.CurrentDeployment.CurrentVersion != ApplicationDeployment.CurrentDeployment.UpdatedVersion)
{
Application.ExitThread();
Application.Restart();
}
}
not that it matters three years later, but I ended up just parsing the manifest file with xml reader.
To expand on RobinDotNet's solution:
Protip: You can automatically run a program or script to do this for you from inside the .csproj file MSBuild configuration every time you build. I did this for one Web application that I am currently maintaining, executing a Cygwin bash shell script to do some version control h4x to calculate a version number from Git history, then pre-process the assembly information source file compiled into the build output.
A similar thing could be done to parse the ClickOnce version number out of the project file i.e., Project.PropertyGroup.ApplicationRevision and Project.PropertyGroup.ApplicationVersion (albeit I don't know what the version string means, but you can just guess until it breaks and fix it then) and insert that version information into the assembly information.
I don't know when the ClickOnce version is bumped, but probably after the build process so you may need to tinker with this solution to get the new number compiled in. I guess there's always /*h4x*/ +1.
I used Cygwin because *nix scripting is so much better than Windows and interpreted code saves you the trouble of building your pre-build program before building, but you could write the program using whatever technology you wanted (including C#/.NET). The command line for the pre-processor goes inside the PreBuildEvent:
<PropertyGroup>
<PreBuildEvent>
$(CYGWIN_ROOT)bin\bash.exe --login -c refresh-version
</PreBuildEvent>
</PropertyGroup>
As you'd imagine, this happens before the build stage so you can effectively pre-process your source code just before compiling it. I didn't want to be automatically editing the Properties\AssemblyInfo.cs file so to play it safe what I did was create a Properties\VersionInfo.base.cs file that contained a text template of a class with version information and was marked as BuildAction=None in the project settings so that it wasn't compiled with the project:
using System.Reflection;
using EngiCan.Common.Properties;
[assembly: AssemblyVersion("0.$REVNUM_DIV(100)$.$REVNUM_MOD(100)$.$DIRTY$")]
[assembly: AssemblyRevisionIdentifier("$REVID$")]
(A very dirty, poor-man's placeholder syntax resembling Windows' environment variables with some additional h4x thrown in was used for simplicity's/complexity's sake)
AssemblyRevisionIdentifierAttribute was a custom attribute that I created to hold the Git SHA1 since it is much more meaningful to developers than a.b.c.d.
My refresh-version program would then copy that file to Properties\VersionInfo.cs, and then do the substitution of the version information that it already calculated/parsed (I used sed(1) for the substitution, which was another benefit to using Cygwin). Properties\VersionInfo.cs was compiled into the program. That file can start out empty and you should ignore it by your version control system because it is automatically changing and the information to generate it is already stored elsewhere.
Hard code, or... Keep track on your versions (File, Assembly, Deploy) in a database. Make a call to the database with your Assembly and get the Deploy version.
This assumes that you are incrementing your versions in a logical way such that each version type has a relationship. It's a lot of work for such a minor problem. I'd personally go with Jared's solution; although I hate hard coding anything.
Using a build component, you could read the click-once version from the project file and write it automatically to the assembly info so both of them are in sync.
Solution for .NET (Core) 7 and higher
On .net Core, you can read the version number from the environment variable ClickOnce_CurrentVersion.
string versionString = Environment.GetEnvironmentVariable("ClickOnce_CurrentVersion") ?? "0.0.0.0";
Version version= Version.Parse(versionString);
MessageBox.Show(version.ToString());
See documentation
I am doing a project on C# and emgu library.
My code works fine on my computer but when I try to run it on other computers it gives exception here:
haar = new HaarCascade("detector_best.xml");
exception is Unhandled type of exception in Sytem.Typeinitaialization occured in Emgu.CV.
Kindly help me I am giving system environment path and working on Windows. also my file detector_best.xml is in my project's debug folder.
Hope this helps
http://www.emgu.com/wiki/index.php/Setting_up_EMGU_C_Sharp
System.TypeInitializationException: Convertion from Image to Image is not supported by OpenCV
Where * is the the relavent image depth or data type.
This error is thrown up in version 2.3.* onwards and is caused by the programs inability to access opencv_imgproc***.dll or opencv_core***.dll even though they are present in the output "bin" directory.
There are two solutions, adding them to the project and set there properties to copy always as they are the two key files. Or by replacing the current ones in the Bin folder with new copies can also solve the problem.
If both methods fail then there may be a problem with the build so download a new copy from SourceForge and try again.
I hope this article sets you on the right path, Thanks for reading.
It works when i added all .dll files from C:\Emgu\emgucv-windows-universal-cuda 2.4.10.1940\bin to myproject\debug folderalso .dll from x86 and x64 from emgu Bin to my project debug like that,C:\Emgu\emgucv-windows-universal-cuda 2.4.10.1940\bin\x86 to myproject\debug\x86 and C:\Emgu\emgucv-windows-universal-cuda 2.4.10.1940\bin\x64 to myproject\debug\x64
I have an application that has an Image Capture feature.
When I try to build it in Visual Studio 2012, I get missing references to Expression Encoder. The image capture facility has been achieved using Microsoft Expression Encoder, and it uses code from it's API. In order to build this application successfully, the PC where I'm trying to build needs some sort of Expression Encoder codec where it will get the references from.
I have tried installing the full application (Microsoft Expression Encoder 4) which is about 25MB, which fixes all the references. We do not want that, due to the application being offered to clients, which means they will have to install another application, the Expression Encoder 4 on top of our application. I'm thinking that there must be a codec of some sort that contains these missing references which is of course smaller than 25MB.
The missing references are the following:
Microsoft.Expression.Encoder.Devices;
Microsoft.Expression.Encoder.Live;
LiveJob
LiveDeviceSource
EncoderDevices
EncoderDeviceType
EncoderDevice
Source Properties
Preview Window
Does anyone have more experience with this and knows how to fix the missing references?
Thank you very much.
Here's an article that shows workarounds for missing Microsoft.Expression.Encoder.resources.dll file, I was able to get through all exceptions using it, but got stuck on 'Appliation not licensed. To fix, install and run application.'
Link to article:
http://uprightbassics.blogspot.com/2014/01/how-to-deploy-expression-encoder-4-sdk.html
This is not possible to deploy an application that uses EE4 SDK without installing the entire application on the target machine. Things had to change from EE3 to EE4 but it does not. Even if you try to "copy local" DLLs in your application location, it requires to install the 25MB EE4 application.
Hope this helps.
Add reference to
microsoft.expression.encoder.dll
Check in C:\Program Files (x86)\Microsoft SDKs\Expression\Encorder 4
If possible copy the dll into your project and change the property Copy To Output to Copy Always.
I am not able to add Leap.dll and Leapcsharp.dll from Leap SDK in given Visual studio project.I am using VS2012 express for Windows Desktop.
I have downloaded sdk from leapmotion site.I get error as "A reference could not be loaded.Please make sure that file is accessible and that is valid assembly or COM component."
Up one directory from the leap.dll and leapcsharp.dll is LeapCSharp.NET3.5.dll and LeapCSharp.NET4.0.dll.
(LeapDeveloperKit\LeapSDK\lib)
These are the tools for Visual studio references.
If you want to use the leap.dll file then you'll need to use P/Invoke
EDIT:
Perhaps you could check out this leap tutorial, complete with code examples.
Here is a better P/Invoke tutorial.
Using an application like DLL Export Viewer you can see all the methods available for your leap dll's. These would be your entry points using P/Invoke. There is also a PInvoke assistance tool that will write your c# for you.
However, doing this with the leap.dll:
[DllImport("leap.dll")]
public static extern bool hasFocus();
Is the same as doing this with the LeapCSharp.Net4.0 dll reference:
Leap.Controller con = new Controller();
var focus = con.HasFocus;
So you dont need both sets of DLL's.
from Leap Motion Developper Documentation
On Windows, make sure that Sample.exe, and
either LeapCSharp.NET3.5.dll, or LeapCSharp.NET4.0.dll are in the
current directory. Use the libraries in the lib\x86 directory for
32-bit projects. Use the libraries in the lib\x64 directory for 64-bit
projects. [...]
You only need LeapCSharp.NET3.5.dll, or LeapCSharp.NET4.0.dll to compile your project. But you'll need the unmanaged libraries Leap.dll and LeapCSharp.dll to run your application (which are in lib\x86 or lib\x64 in the Leap SDK)
Personally I put these unmanaged libraries in a App_Bin\<platform name> folder (<platform name> = x84 or x64) under the solution directory and I use the following post-build command to copy them to the compiler output directory (e.g. MyProject\bin\x64\Debug)
xcopy /Y /D "$(ProjectDir)..\App_Bin\$(PlatformName)\*.*" "$(ProjectDir)bin\$(PlatformName)\$(ConfigurationName)\"
I had the same problem.
You have to add an existing item to your solution and select the files Leap.dll, LeapCSharp.dll from the folder: LeapDeveloperKit\LeapSDK\lib(x86 or x64) and LeapCSharp.NET4.0.dll or LeapCSharp.NET3.5.dll (it depends if you are using framework 4 or 3.5 in your current project) from folder: LeapDeveloperKit\LeapSDK\lib. Then you have to do rigth click in each one of them and select the Properties option. You have to ensure that the "Copy to Output Directory" option is selected with "copy allwas" option (that's very important). Then you have to do rigth click in the References -> Add Reference -> Browse -> select your proyect (your current solution)-> select LeapCSharp.NET4.0.dll (from folder)-> ok. That's all.
or
See this video min 11:29. She tells you better.
You simply need to add the files Leap.dll and LeapCSharp.dll to your project.
And set the file property in Visual studio
Copy to output directory = Copy Always;
Also add a reference to the project of LeapCSharp.NET4.0.dll or LeapCSharp.NET3.5.dll to your project. the reference must correspond to the machine type being used to debug or release the project. These files come to you within the SDK
This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?
I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)
I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.
Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.
In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.
Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.
With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.
Unload the project that has the file that is causing the error.
Reload the project.
Fixed
I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.
In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.
This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.
My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.
I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.
I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.
My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.
In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.
solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project
I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.
My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.
I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!
I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.
I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.
This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.
Delete all breakpoints.
Rebuild.
Done
At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.
Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory
I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..
In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.
Debug-> start without debugging.
This option worked for me. Hope this helps!