顯示具有 C# 標籤的文章。 顯示所有文章
顯示具有 C# 標籤的文章。 顯示所有文章

2020年11月4日 星期三

C# Windows Media Player control COM component failed to play ANY video files

I have fixed the issue which .NET win form failed to play video file with COM component windows media player control.
The error was raised while wmp control invokes d3d9.dll ( Direct 3D 9 runtime ) because I checked out in the windows event manager : 

Faulting application name: WindowsFormsApp1.exe, version: 1.0.0.0, time stamp: 0xf57ea874
Faulting module name: D3D9.DLL, version: 10.0.17763.1075, time stamp: 0x3cad74b1
Exception code: 0xc0000005
Fault offset: 0x000479ff
Faulting process id: 0x1d94
Faulting application start time: 0x01d6b2c1a4facaac
Faulting application path: C:\Users\A30336\OneDrive\Project\Jack Yeh\YehProject\WindowsFormsApp1\WindowsFormsApp1\bin\Debug\WindowsFormsApp1.exe
Faulting module path: C:\Windows\SYSTEM32\D3D9.DLL
Report Id: 004f8352-5e8b-4cda-a346-b278d57514db
Faulting package full name: 
Faulting package-relative application ID: 
And this error resembles the below issue : media player won't play any video file.

Link you gave me assumes i have access violation which i dont.

Besides windows media player, everything else works, games, 3d modeling software to name a few.

I was able to transfer DLL files from another computer and it fixed the problem.

I had to use Unlocker to delete original once and then place good once inside and reboot.

How ever, upon checking checksum of both and comparing them, they were identical.

I am clueless what went wrong and what fixed it because everytime my computer restarts, system is being restored to its original state. I did disabled that feature while i was replacing DLL's

Not sure what to conclude here.


At first, I supposed the DirectX is broken. or wrong linked library for media player control. I can play video file with Windows Media Player but it failed to play in my win form program media player control. So I downloaded latest DirectX redistribution :

DirectX RunTime_Jun2010_redist
Despite it doesn't help. I kept googling and then I got a clue here.

I downloaded and installed the DX Setup app you referenced. The installer reported that it was successful. I restarted my PC, and I still get the same d3d9.dll errors on *any* DX9 app. It turns out, however, I have found the problem. This problem has existed since Win7 was released. d3d9.dll (6.x-10.x) is brittle and poorly written apps can screw with it, causing subsequent dx9 apps to crash. In my case, it was one of the ASUS motherboard monitoring apps that came with my motherboard. Once this app was stopped (it ran fine), other dx9 apps started working perfectly. This was a constant problem for me because I had the monitoring app running on startup.

Solved : I guessed the issue came from wrong file invoking link or broken DLL files. So that I tried to reinstall display chip drivers which contains all the Direct3D or and other related DLLs. My display chip is AMD Radeon HD 8500M/8700M family. So that I checked the AMD website and downloaded , then installed AMD Radeon™ Software Adrenalin 2020 Edition.
I restarted computer. And open my .NET win form program to play video file with WMP COM component. Eventually it works.

2016年5月31日 星期二

How to rebuild ASP.NET Precompiled Website with no source code 如何重建沒有原始碼而已預編譯的ASP.NET站台

  1. 使用de-compile軟體,我使用的是.NET Reflector 7.
    1. 用它開啟編譯的.DLL(如下圖)
    2. 用它開啟編譯的.DLL
    3. 檔案會被分成_ASP ASP兩個命名空間,_ASP是程式的起始點來建立各aspx檔的內容,ASP裡面則是實際程式化建立各網頁ASP控制項。下圖為default.aspx的建構式,裡面會有程式碼來源為哪些頁面。
    4. 這個FrameworkInitialize() 看起來應該是是頁面的起始函式,然後會呼叫_BuildControlTree()去建立所有的控制項,你必須整個走一遍這個部分,因為要重建aspx
    5. 有的時候你必須去看輸出的HTML的source,並與de-coompile後的source對應,找出正確的型別。
    6. GridView的話,要對應到各控制項,找出設定的參數值。
    7. 重建.cs檔相對比較簡單,只需要把反組譯後的程式碼複製出來即可。

2011年2月12日 星期六

透過ISP的網路使用IIS Smtp Service寄送郵件

昨天在岳父家開發公司的簽核網頁程式時,本來work的郵件寄送功能突然無法運作,Check了一下才發現,Hinet的網路會阻止我發送mail到外部,我想這應該是為了阻擋垃圾郵件的關係.查了一些方法都沒有解決問題.本來想透過修改網路route設定的方式,想辦法走公司VPN來發送郵件看看能不能跳過ISP的網路,由於學藝不精,試了很多種方式都沒辦法達成目的,後來就放棄了.

睡了一晚的隔天,突然想到可以查看看,與ISP相關的關鍵字加上IIS Smtp等等.
http://www.google.com.tw/search?sourceid=chrome&ie=UTF-8&q=iis+smtp+%E4%B8%AD%E8%8F%AF%E9%9B%BB%E4%BF%A1

後來查到Hinet環境下有關IIS Smtp智慧主機的設定,但家裡是振道電視,因此就又查了振道那邊提供的smtp server,然後把smtp server設定到IIS Smtp Service的智慧主機上,就可以發信了.

2009年3月19日 星期四

反駁有關CSLA.NET的問題(Rebutting some questions about CSLA .NET)

最近我收了一封信,我想與大家分享我的回應.

Rocky,

我們的公司將要在開發軟體的方式上轉型.我們是一間非常大的公司,辦公室遍佈全球.目前只有我所在的地方使用CSLA.如今公司其他人打算建立一個認可過的方法論"工具箱",現在我們必須保護使用CSLA的決定.從一般情況看來,我覺得這是個好主意.但就現有情況看來,似乎提供建議方案的人來與我們面談,不是為了找出我們有沒有作對什麼事,特別是我們用的東西來自於CSLA.

現在,我了解我能很好的提出質疑...但是,我認為你的幫助將非常有價值.這裡有一些有關CSLA意見的列表,我覺得我必須清楚的反駁.就個人立場我知道他們客觀上是錯的,然而,他們似乎對於CSLA有著普遍的誤解.你認為呢?再提醒一次,這些都不是我的意見,只是我從公司其他人聽來的誤解,我需要把它弄清楚.以及,有一項關鍵性的誤解是我們應該使用Enterprise Library以取代CSLA,再一次強調,他們不了解到底CSLA.NET是什麼東東.

誤解

1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.

2. 許多CSLA的功能可以用Enterprise Library達成.

3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構

4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.

5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.

6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只是後知後覺.

這些是我覺得應該要釐清最關鍵的幾項錯誤想法...你能對於我形成中的論點提供任何協助,我將大大的感激.

感恩!

Jimbo

我的回覆如下:

Jimbo,

1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.

這絕對不是事實,在COM-based CSLA與CSLA.NET有非常多且完整的更動.沒有程式碼被搬移過來,事實是CSLA .NET中的概念已經被.NET自己使用了,參考COM的部份是很有限的.

長久以來,CSLA的確到處都使用了某些OO概念.這些概念經歷了許多時間的測試都保留下來了,也證實對於設計與建構軟體非常的有價值.只因為它們由來已久就拋棄掉好的觀念是很愚蠢的.就如同因為輪子是舊有思維而把輪子丟掉一樣.

各位必須要認知到非常重要的一點,CSLA .NET與Enterprise Library是完全互補的.CSLA .NET提出一套解決方案解決了Enterprise Library未對付的問題,而Enterprise Library則提出一套解決方案解決了CSLA .NET未對付的問題.

2. 許多CSLA的功能可以用Enterprise Library達成.

再提一次, EntLib與CSLA .NET是互補的.像是日誌,快取,資料存取,系統設定.而日誌功能便在CSLA .NET的範圍之外.

而像是資料驗證,身分認證,資料繫結的支援與針對資料n-tier的位置通透性則是CSLA .NET關注的重點.

當然EntLib也有資料驗證模組,在架構上並不穩固,把商務邏輯放進使用者介面層還不如封裝到獨立的商務層.(譯者註:本人認為這兩者應該都需要,UI跟Business都需要資料驗證)

3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構

無疑的使用一個特定應用的架構是一種風險.在此事項上,任何使用CSLA .NET的組織必須清楚了解架構的本質.

然而,要明白另一點也很重要,CSLA .NET是一個使用.NET類型而被廣泛使用的架構.雖然EntLib的確更廣泛被使用,但並非複製或取代CSLA .NET所提供的功能.

如果你未使用CSLA .NET,你仍需要解決它所對付的相關問題.無論喜不喜歡,在.NET中到處都是資料繫結,資料驗證,身分認證與等等需要跨越的障礙. CSLA .NET排除了這些障礙.如同其他產品像是NetTiers, LLBLGen, Ideablade與其他的產品.有些是商業產品,有些則不是.

但目前沒有一個擁有像CSLA .NET這樣廣泛的使用者基礎.

已經有好幾個人在研討會上找我討論並指出他們寫了CSLA .NET的複製品.他們已經閱讀了我的書,不想要使用所謂"特定應用的架構"並且開始自己弄自己的東西.幾個月以後,觀察應用程式並發現到他們又重複解決了所有的同樣的問題.處理所有的同樣的障礙.並且他們用更多程式重建了CSLA .NET.通常他們因此很難過,了解到他們浪費了多少時間去重建一套已經存在的架構.

4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.

這顯然不是事實.抱歉,但是CSLA .NET 2.0在觀念上特別是為了WCF與WPF而開發的.我在微軟的技術先驅團隊中,並提供許多協助以形塑許多這些開發者導向產品的本體.我在.NET 3.0完成多年前就了解其基本的型態與架構,因此在2005年CSLA .NET已經為這些新技術作好準備.

儘管在對此產品評估的言論裡面,其他大部分尖銳的批評是合理的且考慮周詳的(雖然我清楚的反駁某些結論),這一項質疑卻完全是荒謬的且漠視了我已經花在過去四年多的幾百個小時的工作.也忽視了這些年來確保CSLA .NET提供無縫與簡單的更新路徑,從Windows Forms, Web Forms 到 WPF,以及從Web Services 或 Remoting 到 WCF.

我想提出一項挑戰,看看有沒有人能找出另一個架構能讓使用者透過簡單的修改設定檔就能從Web services或Remoting切換到WCF.並且藉由我為這些技術準備的方法我在2004與2005就在CSLA .NET中完成了這些功能.

5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.

此處有兩個觀點.

第一, CSLA是一個品牌. 無論是"以元件為基礎可調較的邏輯架構"是否仍能正確的描述(這不能)都不再重要,因為這個品牌就是它自己.換句話說,不要太鑽研它的名字 - 我被它搞的很煩.

第二, 無疑的CSLA設計用來支援n-tier的主從端架構.這樣的架構目前是使用WPF, Windows Forms與Web Forms介面建構互動應用程式最好的方式.無論喜不喜歡它,SOA有太多多餘工作負荷並且對於大多數互動性應用程式開發來說成本太高.

認為物件導向設計在面臨SOA或者workflow時會被消滅是很蠢的.事實上它們是高度互補的.

一項服務或者一個工作流的活動從定義看來都是基本功能單位.如果他們不是,那麼你就弄錯了.

實際上每項服務與每項活動是"迷你應用程式".它們實際上也是一個使用者案例,從一個物件導向設計(OOD)的觀點看來.

例如:你可以(並且應該常常)使用OO概念設計並實作你的服務與活動.所有有關於讓物件導向設計/程式開發(OOD/P)用於打造應用程式上的相關事宜,CSLA .NET都能夠讓它變的更簡單.

結論是,無論你正在打造消費服務的應用程式或者生產服務及活動的應用程式,CSLA .NET都有很大的幫助.

6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只不過是後知後覺.

事實是CSLA .NET已經能夠有大量使用者作為後盾,他們來自於微軟平台上快速增長中的更新與混亂的地帶.藉由清楚的在使用者介面與商務邏輯間的程式碼間強化邊界的輪廓,並藉由支援.NET標準的資料繫結與.NET功能的使用者介面, CSLA .NET持續擔任一個有價值的緩衝區,允許有價值的商務邏輯更容易隨著時間發展,即使使用者介面技術改變又改變再改變.

為了對付微軟平台的快速變革,我會花更多時間替CSLA .NET或者更重要的CSLA .NET的使用者建立"不會過時的技術",但明顯的要抽象化所有微軟發表的變更是不可能的,但是CSLA .NET努力保護其中最重要的以及在維護與建構上最耗成本的:你們的商務規則與邏輯.

原文見此

2009年3月18日 星期三

比較CSLA.NET 與 Enterprise Library (CSLA .NET compared to Enterprise Library)

CSLA .NET compared to Enterprise Library
比較

在微軟Patterns & Practices討論群組中許多人問過Enterprise Library與CSLA .NET 2.0兩者的對比關係為何?

我所寫的書(例如CSLA .NET 2.0)針對如何建立一個物件導向的商務層,靠著提供正確性檢查,身分驗證,資料繫結,回溯功能與堅固性,此層可使你的商務物件支援各式使用者介面(Windows, Web, Web services, WPF, 等等).這允許使用者介面完全專注處理顯示與使用者互動的問題,把所有商務邏輯與流程都交給商務物件.

Enterprise Library是很棒的應用程式區塊的集合,用以處理有關日誌,例外處理,資料存取等等的問題.P&P團隊建立了多種其他的應用程式區塊到此類別庫(EntLib)內.到目前為止,無論是EntLib類別庫或是其他的應用程式區塊都並未針對商務層的設計與建構.

CSLA .NET與EntLib類別庫是互補的.你可以同時使用CSLA .NET與EntLib的元件,也可以同時使用其他由P&P Group開發的其他應用程式區塊.

P&P Group = MS's Patterns & Practices Group
EntLib = Enterprise Library

原文見此