TL;DR Why is it when running debug mode my application works but in release it does not?
I am using MVVM to load a file path to process some data. When I am using the debugger version it loads, validates and converts fine, but when I am using the published/released version it fails so I am unable to track where it occurs. One note is that we tried to accompanied long file paths so we included #"\\?\"
Attached is our converter.
public static string CheckFilePath(string filePath)
{
//Network Location
if (filePath.StartsWith(#"\\"))
{
filePath = filePath.TrimStart(#"\\".ToCharArray());
return #"\\?\unc\" + filePath;
}
//Local location
if (!filePath.StartsWith(#"\\?\") && (!filePath.StartsWith(#"\\") || !filePath.StartsWith(#"\\?\UNC\")))
{
return #"\\?\" + filePath;
}
return filePath;
}
Also we're using 4.6.2 and using this to try and accomodate long file paths. Please note this is just my converter to check to see if it has a #"\\?\" or a #"\\" and replaces it with the following required for a long path. This converter may not be the problem... Any help would be great!
Alright everyone thanks for the help, but I found a workaround. Turns out there is something wrong with my published version versus my release version kind of like what jdweng said. If I just run the executable from the release it works, but when I try to install it via publish, it does not.
Related
I'm running into problems writing an application to batch load and export files in AutoCAD using a C#. I've received numerous errors listed below whenever I point to a folder full of .dxf files. I've been able to narrow the problem down to the point where I know it's only breaking on load. Sometimes it loads fine, others it will only load 3-4 files, and the rest of the time it will simply throw an error. The errors I'm seeing include but are not limited to FaultExecutionEngineError, NullExceptionError, IndexOutOfRange error, and the wonderful FATAL EXCEPTION error, which causes Autocad to crash as well.
Here is my code:
public class MyCommands
{
string folderPath = #"C:\Users\kdhyne\Desktop\New folder\";
// Modal Command with localized name
[CommandMethod("FileCycle", CommandFlags.Session)]
public void MyCommand() // This method can have any name
{
var acDocManager = Autodesk.AutoCAD.ApplicationServices.Application.DocumentManager;
string[] filesInDirectory;
Document acDoc = null;
filesInDirectory = Directory.GetFiles(folderPath, "*.dxf", SearchOption.TopDirectoryOnly);
foreach (string someFile in filesInDirectory)
{
acDoc = acDocManager.Open(someFile);
}
}
}
I've stripped this down as far as I can think. Hopefully someone can help. Thank you for reading.
Do a release build before opening it in AutoCAD and it seems to work fine! Apparently it wasn't compiling all the libraries into the debug build.
I have made a change to a method used in a Functiod in a mapping file but it seems the new code is not taking effect, ever.
I have deployed properly, started the application, restarted related host instance (actually all host instances I could find) and still, the old code seems to execute.
Here's the, simple, method:
public string RemoveNonNumericChars(string stIn, int maxLength)
{
string strOut;
try
{
strOut = Regex.Replace(stIn, "[^0-9]", "");
System.Diagnostics.EventLog.WriteEntry("BizTalk Server 2009", strOut);
return strOut.Substring(0, maxLength);
}
catch
{
return string.Empty;
}
}
I added the writing to EventLog line to see that this code is indeed being executed, but I don't get anything in "Application" event logs.
I do NOT get an empty string being returned, so it really does seem like the old code that's being executed prior to me fixing the method.
What am I missing exactly ?
Thank you.
For some reason, the script is not able to correctly retrieve the Build Config selected in Visual Studio, it's taken from Debug when I'm actually trying to build it for a Test environment. I should have known, thanks anyways.
On Windows, I have a C# assembly that is COM visible. It references other assemblies to control an application in the machine. It works fine.
However, under Apache Web Server and using CGI, it doesn't work. After doing some debuging, I found out that the problem is that, while running under Apache's CGI, the environment variables SYSTEMROOT and SYSTEMDRIVE, which aparently are needed by the referenced assemblies, are not loaded.
I can configure Apache to pass those environemtn variables too, but before doing so, I'd really like to know if there's some command I can put on my C# COM visible assembly to make it load environment variables as if it was, let's say, the SYSTEM user or something like that, so it doesn't have to relay on the environment passed by the starting application.
How do you force loading an existent system environment variable in C#, when IT IS NOT SET in the current process (or it was process-deleted by the launching process)?
Thanks in advance for any suggestions!
EDIT 1 - ADDED INFO: Just to make it more clear (as I see in the current answers it's not so clear): Apache intendedly deletes a lot of environment variables for CGI processes. It's not that Apache cannot see them, it can, but it won't pass them to CGI processes.
This should do the trick:
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
I did a small test and it is working:
//has the value
string a = Environment.GetEnvironmentVariable("TMP");
Environment.SetEnvironmentVariable("TMP", null);
//does not have has the value
a = Environment.GetEnvironmentVariable("TMP");
//has the value
a = Environment.GetEnvironmentVariable("TMP", EnvironmentVariableTarget.Machine);
SOLUTION: Marco's answer was great and technically answered my question - except that I found out that the environment variables SYSTEMROOT and SYSTEMDRIVE are not really set in the registry where all environment variables are set, so, the chosen answer works for all variables except those two, which I specified in the OP.
SYSTEMROOT is defined on the registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot, and apparently (after more research), SYSTEMDRIVE is generated as a substring of SYSTEMDRIVE.
So, to get SYSTEMDRIVE and SYSTEMROOT from registry and load them into the environment:
using Microsoft.Win32;
namespace MySpace
{
public class Setup
{
public Setup()
{
SetUpEnvironment();
}
private void SetUpEnvironment()
{
string test_a = Environment.GetEnvironmentVariable("SYSTEMDRIVE", EnvironmentVariableTarget.Process);
string test_b = Environment.GetEnvironmentVariable("SYSTEMROOT", EnvironmentVariableTarget.Process);
if (test_a == null || test_a.Length == 0 || test_b == null || test_b.Length == 0)
{
string RegistryPath = "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion";
string SYSTEMROOT = (string) Registry.GetValue(RegistryPath, "SystemRoot", null);
if (SYSTEMROOT == null)
{
throw new System.ApplicationException("Cannot access registry key " + RegistryPath);
}
string SYSTEMDRIVE = SYSTEMROOT.Substring(0, SYSTEMROOT.IndexOf(':') + 1);
Environment.SetEnvironmentVariable("SYSTEMROOT", SYSTEMROOT, EnvironmentVariableTarget.Process);
Environment.SetEnvironmentVariable("SYSTEMDRIVE", SYSTEMDRIVE, EnvironmentVariableTarget.Process);
}
}
}
}
Then you can just call Setup setup = new Setup(); from other classes. And that's it. :-)
Environment.GetEnvironmentVariable
see reference here.
e.g.
Environment.CurrentDirectory = Environment.GetEnvironmentVariable("windir");
DirectoryInfo info = new DirectoryInfo(".");
lock(info)
{
Console.WriteLine("Directory Info: "+info.FullName);
}
Are the variables set as system wide?
If they are not, that is what you need to do, otherwise create user variables for the user the COM is running under.
Thank you. I cannot state with any certainty that this has once and for all driven a stake through the heart of the vampire, but amazingly enough, the error has disappeared (for now). The odd thing is that access to the statement
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
is a real oddity in the debugger. It does not show up in Intellisense and does not even appear to fire, which leads me to suspect, which you all knew already, that this is some sort of magic runtime object Environment that has no instantiation in the debugger but also can be benignly jumped over. Oh well.
Oh and I should mention that after you see that error, you will note oddities in your Windows OS, which is worrisome. In particular, you will see, if you try to use the Control Panel /System/Advanced Properties (whatever) that it cannot load the dialog for the environment variables any more, indicating that %windir% has been seriously hosed (compromised) across all applications. Bad bad bad....
I have spent quite a while trying to solve this problem, but to no avail. I have searched stackoverflow as well as Google and have not been able to resolve my (seemingly) simple problem.
I am getting a FileNotFoundException in the following line:
Image.FromFile("\\Resources\\Icons\\key-icon.png");
The folders and image are really there, and I can't see what the problem is.
You should consider that it is started from "yourproject/bin/Release" so you need to go up 2 directories. Do this:
Image.FromFile("..\\..\\Resources\\Icons\\key-icon.png");
Try using an absolute path not a relative one... i.e.
Image.FromFile(Server.MapPath(#"~\Resources\Icons\key-icon.png"));
Image.FromFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
#"Resources\\Icons\\key-icon.png"))
Base-directory Combine your file-name
You may be missing a leading ".":
Image.FromFile(".\\Resources\\Icons\\key-icon.png");
Internally, Image.FromFile uses File.Exists to check whether the file exists. This method returns false when:
the file does not exist (makes sense)
the current process identity does not have permission to read the file
It may be that the second option is your problem.
And another possibility: is Resources a network share? In that case you should use the following:
Image.FromFile("\\\\Resources\\Icons\\key-icon.png");
For this case I discovered that sikuli does not automatically detect the root folder of the project. What you should do for this case is specify the folder using the command System.getProperty("user.dir");
import org.sikuli.script.*;
public class Test {
public static void main(String[] args) {
Screen s = new Screen();
try{
String pathYourSystem = System.getProperty("user.dir") + "\\";
s.click(pathYourSystem + "imgs/spotlight.png");
//s.wait(pathYourSystem + "imgs/spotlight-input.png");
//s.click();
s.write("hello world#ENTER.");
}
catch(FindFailed e){
e.printStackTrace();
}
}
}
I want to get the path and version number of a ClickOnce application, provided the name of the ClickOnce application.
When I manually searched for it, I found it at the path as follows:
'C:\Users\krishnaim\AppData\Local\Apps\2.0\1HCG3KL0.K41\VO5BM4JR.RPO\head..tion_7446cb71d1187222_0005.0037_37dfcf0728461a82\HeadCount.exe'
But this keeps on changing, and it will become a hard-coded path. Is there another way to get a ClickOnce application (for example, HeadCount.exe which is already installed) path and version number using C#/.NET code?
It seems a little bizarre, but getting the current directory of the executing assembly is a bit tricky so my code below may be doing more than you think it should, but I assure you it is mitigating some issues where others may attempt to use Assembly.GetExecutingAssembly.Location property.
static public string AssemblyDirectory
{
get
{
//Don't use Assembly.GetExecutingAssembly().Location, instead use the CodeBase property
string codeBase = Assembly.GetExecutingAssembly().CodeBase;
UriBuilder uri = new UriBuilder(codeBase);
string path = Uri.UnescapeDataString(uri.Path);
return System.IO.Path.GetDirectoryName(path);
}
}
static public string AssemblyVersion
{
get
{
var asm = Assembly.GetExecutingAssembly();
//If you want the full four-part version number:
return asm.GetName().Version.ToString(4);
//You can reference asm.GetName().Version to get Major, Minor, MajorRevision, MinorRevision
//components individually and do with them as you please.
}
}
In order to do a ClickOnce application update you do not have to do so manually as long as you are using the standard deployment manifests (which I don't know how to ClickOnce unless you do use them).
The MSDN article Choosing a ClickOnce Update Strategy describes the different options for application updates.